Linus Torvalds : l’interview anniversaire des 20 ans du noyau

Posté par patrick_g (site web personnel) le 03 mai 2011 à 20:58. Édité par Benoît Sibaud. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

211

mai

2011

Il est bien difficile de déterminer la date de naissance exacte du noyau Linux. Est-ce qu’elle se situe en avril 1991, quand Linus Torvalds a réellement commencé à travailler sur son projet de nouveau noyau ? Est‐ce le 25 août 1991, quand il a posté son célèbre message (« just a hobby, won’t be big and professional like GNU ») sur le newsgroup comp.os.minix ? Est‐ce que nous devons retenir le mois de septembre 1991 quand la version 0.01 a été déposée sur le serveur FTP de l’Université de technologie d’Helsinki ?

Quelle que soit l’option retenue, l’année 2011 marque le vingtième anniversaire de ce prodigieux projet et, pour participer aux célébrations, LinuxFr a réalisé une interview de Linus Torvalds, dont vous trouverez une traduction en seconde partie de la dépêche.

Bien entendu, je recommande vigoureusement aux anglophones de lire la version originale de l’interview qui est présente en commentaire. Linus utilise souvent des expressions idiomatiques et le « Traduttore, traditore » est plus que jamais valable !

LinuxFr : Tu travailles sur le noyau Linux depuis 20 ans maintenant et c’est un boulot difficile. Est‐ce que c’est toujours fun ?

Linus Torvalds : Oh absolument, c’est toujours fun. Et en partie parce que je fais ça depuis 20 ans, je ne dirais pas que c’est difficile. Cela reste stimulant et intéressant, mais je pense que je suis bon dans ce domaine.

LinuxFr : Pourquoi est‐ce que tu as choisi de passer le noyau sous licence GPL, alors que ta première licence n’était pas la GPL ? Est‐ce que c’était un choix pratique ou bien un choix éthique ?

Linus Torvalds : Pratique. Je pense que ma première licence contenait les parties éthiques qui étaient importantes pour moi, mais il s’est avéré qu’elle était trop stricte en ce qui concerne la partie « non‐commerciale », et en plus, elle n’était pas assez reconnue. Le passage sous licence GPL a corrigé les problèmes que les gens avaient avec ma première licence. En plus, cela nous a permis de rejoindre une licence connue qui avait bien plus de chance de tenir debout devant une cour de justice, par rapport au truc succinct que j’avais écrit à l’origine.

LinuxFr : Je sais que tu te considères comme une personne pragmatique et pas comme un prophète… Mais, est‐ce que tu serais d’accord pour dire qu’il y a un contenu de nature éthique dans la licence GPL ?

Linus Torvalds : Je vais répondre à ça de deux façons différentes, et je vais essayer d’expliquer pourquoi je réponds de deux façons différentes.
La première réponse, très négative, c’est que je méprise complètement les gens qui tentent de pousser la GPL comme étant de type « éthique ». Je pense que c’est de la pure connerie. Pourquoi ? Parce que l’éthique, pour moi, c’est quelque chose de privé. Chaque fois que vous l’utilisez dans un argument pour dire pourquoi quelqu’un d’autre devrait faire un truc, alors vous n’êtes plus éthique. Vous devenez juste une tête de con moralisatrice.

Mais la seconde réponse, c’est que personnellement je pense que la GPL (version 2) correspond à ce que je veux faire. J’aime vraiment programmer et je veux rendre disponible mon travail pour que les autres puissent en profiter. Mais je pense vraiment que tout le « vous pouvez faire ce que vous voulez, mais vos améliorations doivent être disponibles de la même manière que le code d’origine » est très juste, et que c’est un très bon moyen de faire du développement.

Donc, personnellement, je pense que la GPLv2 correspond d’assez près à ce que je pense être « la bonne manière de vivre ma vie ». Et par « bonne manière », je ne veux pas dire que ce soit la seule manière. J’ai fait aussi du développement sous licence commerciale et j’ai beaucoup aimé ça. Je pense que c’est aussi correct et approprié (Eh, ils m’ont payé pour le faire).

Donc, je pense que la GPLv2 est une bonne licence et je l’utilise pour mes propres raisons personnelles. Je pense que c’est aussi vrai pour de nombreuses autres personnes, mais je veux vraiment préciser que ce n’est pas la licence qui est éthique en elle‐même. Beaucoup d’autres personnes pensent que la licence BSD, avec ses libertés encore plus étendues, est une meilleure licence pour eux. Et d’autres préféreront utiliser une licence qui conserve tous les droits au propriétaire du copyright et qui ne donnera aucun droit sur les sources aux autres personnes. Et pour eux, c’est leur réponse. Et c’est bien, c’est leur choix.
Essayer de promouvoir une licence particulière comme étant « le choix éthique » me rend malade. Vraiment.

LinuxFr : Pourquoi est‐ce que le « desktop » est si spécial et tellement plus difficile à investir que les autres marchés ?

Linus Torvalds : Parce qu’il est bien plus intéressant. C’est le marché sur lequel les gens font tant de choses différentes.

Un serveur typique ne fait presque rien. C’est vrai, il peut avoir une grosse puissance processeur, un réseau rapide et des tonnes d’entrées-sorties, mais il fait le même truc encore et encore, et ce « même truc » est vraiment limité. Cela consiste à gérer une base de données, un serveur de courrier ou de pages Web, à faire de l’analyse de données, etc.. C’est peut être important pour une entreprise, mais ce n’est pas une charge de travail très variée et ce n’est pas une chose à laquelle les gens sont attachés.

Par contraste, le desktop, c’est ce que vous voyez tous les jours et auquel vous devenez attaché. Cet attachement peut être une sorte de « syndrome de Stockholm » où vous ne l’aimez pas forcément (pensez à tous ces gens qui ont grandi en connaissant les ordinateurs à travers DOS ou Windows et son salut à trois doigts Ctrl-Alt-Suppr), mais même dans ce cas, cela devient une sorte de dépendance où vous êtes habitués et où vous vous reposez dessus bien plus que vous ne pourriez le faire par rapport au mainframe de l’entreprise.

Et sur une machine de bureau, vous pouvez faire tant de choses en plus. Vous jouez à des jeux, vous faites du traitement de texte dessus. Vous faites vos développements sur cette machine. Ce n’est pas limité à un seul truc.
Bien entendu, pour beaucoup de monde, c’est aussi devenu « vous utilisez un navigateur dessus » et pas grand chose d’autre. Mais, même cette seule utilisation tend à être une charge de travail bien plus complexe que la plupart des charges de travail des serveurs.

Ce qui est intéressant, c’est que les smartphones commencent lentement à partager certaines de ces complexités avec les desktops. Ce n’est pas encore exactement pareil (et ça ne le sera peut‐être jamais vraiment), mais les téléphones ont déjà une bonne part des problèmes riches et complexes qui caractérisent les ordinateurs de bureau, et en plus, ils ont des modes d’utilisation plus variés.

LinuxFr : Pourquoi Linux sur les machines de bureau n’a pas été adopté par la majorité des utilisateurs ? Est‐ce qu’il est possible pour la communauté du noyau d’améliorer la situation, ou bien est‐ce qu’il s’agit surtout d’un problème qui se situe au niveau des applications ?

Linus Torvalds : Je ne crois pas qu’il y ait grand chose que nous puissions faire au niveau du noyau, à part continuer à améliorer les choses en général et faire en sorte que nous restions techniquement le meilleur choix.

Et ce n’est pas comme si nous n’avions pas d’utilisateurs dans le grand public. Android est un exemple d’utilisation grand public de Linux. Le problème, c’est que le desktop est un marché qu’il est difficile d’atteindre. Il y a un énorme « effet réseau » qui fait que lorsque vous avez beaucoup d’utilisateurs, c’est une bonne raison pour les retenir et pour en conquérir de nouveaux.
Il y a aussi le fait que beaucoup de gens ne veulent vraiment, vraiment pas changer leur environnement ; et s’ils sautent le pas, alors ils veulent de l’aide et du support. Ici, « support » n’est pas nécessairement du support commercial, c’est aussi savoir que vous avez des gens autour de vous qui connaissent le système et qui peuvent vous donner des conseils, etc..

Passer ce cap est difficile. Et ce n’est pas quelque chose qui se fait en pointant des problèmes techniques spécifiques. C’est souvent un problème social.

LinuxFr : Je sais que c’est une question étrange (et probablement stupide), mais est‐ce que tu es encore capable de comprendre complètement toutes les parties du noyau Linux, ou bien est‐ce que tu as vraiment besoin de tes mainteneurs ? Par exemple, en ce qui concerne le patch très complexe du « pathname lookup » de Nick Piggin, comment as‐tu fait pour choisir entre cette solution et celle de Dave Chinner ? Est‐ce que tu as reçu des conseils d’Al Viro ou bien est-ce que ça a été une décision solitaire ?

Linus Torvalds : Oh, je ne prétends absolument pas connaître et comprendre toutes les parties du noyau. J’en connais bien plus que la plupart des autres développeurs du noyau, mais il y a des endroits où je me repose presque entièrement sur les mainteneurs. Parce que je n’en connais tout simplement pas assez (ou bien je m’en fiche complètement — nous avons tous nos centres d’intérêt) sur un sous‐système particulier.

Ceci dit l’exemple que tu as choisi ne fait pas partie de ces zones. La couche VFS et la plus grande part du sous‐système de la mémoire virtuelle sont des endroits qui me sont parfaitement familiers, et donc je n’ai aucun problème à prendre moi‐même des décisions et à m’occuper du résultat, même sans aide. Bien entendu, cela ne veut pas dire que je ne m’attends pas à ce que des gens comme Al m’aident, et cela ne veut pas dire que je ne parle pas avec eux à ce sujet. Mais en ce qui concerne le pathname lookup, j’étais bien plus impliqué personnellement que dans la plupart des autres domaines.

Bien entendu, en temps normal, je ne veux pas vraiment me sentir obligé d’intervenir personnellement. Les patches du pathname lookup ont été disponibles pendant près d’un an et nous ne faisions pas beaucoup de progrès dessus (il y a eu des tonnes de discussions, mais pas assez d’avancées par rapport à ce que je voulais). J’ai fini par me faire le champion de ces patches avec un peu plus d’intensité que je ne l’aurais fait en temps normal. J’aurais été parfaitement content de passer par le canal des mainteneurs, comme d’habitude.

Dans d’autres cas, je ne peux pas faire le coup du « je m’implique et je prends la décision finale », parce que je ne connais pas nécessairement le sujet assez bien. Ou alors, parce que je ne me sens pas vraiment pour maintenir moi‐même le truc, si jamais j’emmerde vraiment trop le mainteneur officiel.
Dans ces cas‐là, je me contente de bousculer les gens et de tenter de susciter des discussions à propos des problèmes, mais au final, je dois faire confiance à celui qui s’empare du sujet et qui prend la bonne décision.
D’ailleurs, « bonne décision » n’est peut‐être pas le terme approprié. Parfois, vous devez juste prendre une décision. Il n’est pas toujours évident de savoir quelle est la « bonne » décision, et parfois il peut être bon de se contenter de dire « nous n’en savons rien » et de ne pas prendre de décision du tout. Dans d’autres cas, vous devez vraiment choisir entre des alternatives techniques. La bonne nouvelle, c’est que la plupart des choix techniques peuvent être changés si, plus tard, il s’avère qu’ils étaient erronés. Cela peut être douloureux, mais parfois il vaut mieux faire un choix, même si vous ne savez pas si c’est le bon. Même s’il y a une chance que vous ayez à revenir sur votre décision plus tard.

Je dois dire que ce genre de situation est en réalité assez rare. La plupart du temps, le processus de développement fonctionne sans que personne n’ait à faire de choix particulièrement difficile. La plupart du temps, la direction à prendre est très claire, et ce qui est le plus difficile, c’est de trouver les gens pour écrire vraiment le code :).

LinuxFr : Qu’est‐ce que tu penses de cette citation de Lennart Poettering ? : « En fait, de la façon dont je vois les choses, l’API Linux joue maintenant le rôle de l’API POSIX, et Linux est devenu le point focal de tout le développement du logiciel libre. De ce fait, je ne peux que recommander aux développeurs d’essayer de “hacker” avec seulement Linux en tête, et de faire l’expérience de la liberté que cela apporte et des opportunités que cela vous ouvre. Procurez‐vous une copie du livre “The Linux Programming Interface”, ne vous préoccupez pas de tout ce qui est écrit dedans au sujet de la compatibilité POSIX et écrivez votre super logiciel Linux. Ça soulage ! ».

Linus Torvalds : Eh bien, je pense que cela peut être une façon raisonnable de simplifier un problème très difficile (la portabilité).

Une raison pour laquelle cela peut être une bonne idée, c’est que nous n’essayons vraiment pas d’étendre trop — et jamais gratuitement — les interfaces standard. Même si vous décidez de ne vous préoccuper que de Linux, c’est vraiment dur d’arriver à un résultat final qui sera horriblement non portable. Linux est vraiment un UNIX tout à fait standard dans bien des aspects et, même en dehors des systèmes UNIX, la plupart des frameworks que vous allez utiliser sous Linux sont aussi disponibles sous d’autres plates‐formes (souvent parce que ces frameworks sont open source).

Donc, si vous décidez par la suite qu’après tout, vous voulez être portable, commencer uniquement par Linux n’est probablement pas un mauvais choix. Et cela peut simplifier le processus de décision initial dans un projet.

LinuxFr : Est‐ce que tu penses que systemd est une grosse amélioration par rapport à l’init SysV ? Est‐ce que c’est susceptible de bouleverser la situation ?

Linus Torvalds : Là aussi, j’opterai pour une attitude du type « attendons de voir ». Pour l’instant, ce n’est pas encore assez utilisé pour se faire une opinion. Je suis d’accord pour penser que le temps de démarrage est un facteur important, et tout changement qui peut améliorer les choses et rendre le processus plus flexible, est une bonne chose.
Est‐ce que j’appellerais ça un « bouleversement de la situation » ? Probablement pas.

LinuxFr : Est‐ce que tu utilises Btrfs ? Quand penses‐tu qu’il sera prêt à remplacer ext4 comme système de fichiers recommandé par défaut ?

Linus Torvalds : J’ai utilisé Btrfs sur les quelques portables que j’ai ; mais franchement, quand il s’agit d’utilisation d’un système de fichiers, le facteur principal, c’est le support des distributions. À peu près rien d’autre ne compte, du moment que les fonctions de base sont présentes. Donc, la manière, pour un système de fichiers, de devenir la solution recommandée par tous, c’est qu’il y ait une distribution qui opte pour ce système de fichiers par défaut. Tout simplement parce que les gens ne privilégient pas les fonctions ni les performances, mais la stabilité.

En ce qui me concerne personnellement, je ne me soucie plus de ce genre de truc. J’ai eu des problèmes avec ext3 (en particulier, des performances fsync horribles), mais la plupart de ce que je fais est totalement dominé par la couche VFS, parce qu’elle permet si bien de tout mettre en cache (j’ai les sources du noyau en RAM tout le temps et le système de fichiers n’a aucune importance, parce que toute la mise en cache est effectuée par les routines génériques).

LinuxFr : Avec Linux et Git, tu as créé deux logiciels qui ont changé le monde de l’informatique. Comment est-il possible d’avoir à son actif deux gigantesques succès comme ceux‐là ? Quelle est la différence entre toi et les simples mortels ?

Linus Torvalds : Je pense qu’une bonne part vient juste de ma persévérance obstinée. Spécialement Linux. J’étais au bon endroit et au bon moment, mais d’autres auraient pu créer leur propre système d’exploitation. Et d’ailleurs, d’autres l’ont fait. Mais très peu de gens l’ont fait avec autant d’obstination que moi. Je suis sur ce truc depuis vingt ans.
La plupart des autres développeurs qui bossent sur un quelconque projet privé pour leur propre plaisir, ne persistent pas assez longtemps pour qu’il devienne prêt pour une publication. Encore moins quand on compte en décennies.

Avec Git, les choses sont un peu différentes. En partie parce que j’avais un cas d’utilisation qui était suffisamment important (le noyau) pour que je puisse le lancer, mais aussi en partie parce que je suis vraiment arrivé avec une nouvelle vision sur un problème ancien. Et je pense que j’ai fait du bon boulot en tant qu’architecte du projet. Je pense vraiment que Git a fondamentalement une bonne conception (dans le cas de Linux, je pouvais tout simplement m’appuyer sur la conception d’UNIX qui avait déjà été créé), et j’ai pu l’imposer parce que Linux avait besoin de plus que ce que pouvaient offrir les autres gestionnaires de code.

Mais avec Git, une grande partie de la reconnaissance est en réalité due à Junio Hamano. Il a vraiment été un grand mainteneur. Les gens comme ça sont importants. Oui, c’est vrai, la programmation open source est un sport d’équipe, mais trouver la bonne personne est vraiment d’une importance cruciale (la même chose est évidemment aussi valable en ce qui concerne le noyau — je pense vraiment que nous avons un excellent groupe de mainteneurs. Je peux parfois me plaindre d’eux et je suis tristement célèbre pour mes engueulades quand les choses ne marchent pas, mais en même temps, je suis convaincu qu’il y a quelques‐uns des meilleurs programmeurs existants qui travaillent à maintenir le noyau).

LinuxFr : J’ai vu que tu lisais beaucoup de trucs sur la biologie et la théorie de l’évolution (par exemple, Richard Dawkins). Est‐ce que ces connaissances sont utiles pour le processus de développement de Linux ? Est‐ce qu’il s’agit surtout d’un modèle de compétition darwinien ou bien plutôt d’un modèle coopératif ?

Linus Torvalds : Je ne crois pas que ce soit utile pour le noyau, mais c’est un fait qu’il s’agit d’un domaine qui m’intéresse. La biologie, l’évolution, le comportement humain — ce sont tous des sujets fascinants. Et je pense qu’il y a des parallèles entre le développement technologique et l’évolution. Évidemment, je ne crois pas à l’« intelligent design » quand il s’agit de biologie (et je pense que quiconque croit en ça est dramatiquement mal éduqué), mais après tout, je pense souvent que l’« intelligent design » est aussi très surfait dans le domaine technologique. Beaucoup d’améliorations technologiques semblent vraiment relever d’un mode de développement plus « organique » et très peu d’entre elles sont complètement conçues dès le début.
En fait, je pense que la plupart des problèmes techniques intéressants sont trop compliqués pour pouvoir faire un « design » à leur sujet. La manière d’arriver à une solution, c’est surtout d’avoir des améliorations progressives et de faire des essais et des erreurs.

LinuxFr : Tu es maintenant un citoyen américain. Qu’est‐ce que tu penses de la loi sur les brevets logiciels aux États‐Unis ? Est‐ce que ta voix est suffisamment écoutée pour que tu puisses aider à combattre cette loi dans ce pays ?

Linus Torvalds : Je dois admettre que, même si je n’aime pas les brevets, j’essaie également de me tenir à l’écart pour ne pas être trop impliqué dans des problèmes de cette nature. Je suis bon dans ce que je fais et je pense qu’il y a des gens qui sont meilleurs que moi pour combattre ce bordel des brevets. Et je pense que ça doit être combattu depuis l’intérieur du système — donc je m’attends à ce que la solution vienne en réalité des entreprises qui seront impactées par tout ce bazar.

LinuxFr : Tu écris souvent des messages détaillés sur realworldtech.com, mais je ne t’ai jamais vu poster sur lwn.net. Pourquoi ? Est‐ce que tu lis régulièrement lwn.net ?

Linus Torvalds : Eh, rwt, c’est l’endroit où je vais pour « enflammer » les gens et pour me disputer au sujet des architectures des ordinateurs. J’aime les gens qui répliquent et j’aime aussi le fait que ce ne soit pas des gens impliqués dans Linux, ou même que ce soit sans aucun rapport avec Linux. Donc, je peux balancer mes opinions et voir ce que je reçois en retour.
Avec lwn, ce serait une histoire complètement différente.

LinuxFr : Plusieurs personnes ont critiqué la sécurité du noyau. Est‐ce que tu penses que les développeurs travaillent suffisamment sur les mécanismes de sécurité et sur les revues de code ? Est‐ce que tu penses que des parties de GRSecurity devraient être importées dans la branche principale ?

Linus Torvalds : Je pense que nous avons fait un assez bon travail, mais l’un des problèmes avec le monde de la sécurité, c’est que c’est très noir et blanc. Pour certaines personnes dans la sécurité, même le fait d’employer l’expression « assez bon travail » est un signe d’alerte rouge. Ils ne pensent pas qu’un « assez bon travail » est assez bon. Ils pensent que la sécurité est, en quelque sorte, tout ce qui importe.

Et je ne suis pas d’accord. La plupart des problèmes de sécurité sont juste des bogues. Nous devons essayer d’éviter les bogues, mais les bogues arrivent. C’est un truisme, mais je pense que c’est vraiment à quoi cela se réduit au final. Est‐ce que nous sommes meilleurs pour éviter les bogues que les autres projets ? Je pense que nous ne nous débrouillons pas trop mal, spécialement si on considère la quantité démentielle de code que nous écrivons ou modifions chaque jour.
Je ne crois pas que ce soit utile d’essayer de séparer les « bogues de sécurité » des autres bogues. Ce sont juste des bogues et presque chaque bogue peut être un bogue de sécurité en fonction des circonstances.

Quant à GRSecurity, je pense que nous avons pris les choses importantes et que nous avons laissé de côté les trucs extrêmes (les choses qui gênent vraiment l’utilisation ou qui sont extrêmement intrusives).

En général, la meilleure manière de faire face aux problèmes de sécurité consiste à avoir plusieurs couches de défense. On ne peut jamais éradiquer complètement les bogues dans un quelconque programme digne d’intérêt, mais avec des couches successives de sécurité, l’une d’entre elles finira, je l’espère, par protéger contre un bogue qu’il aurait été possible d’exploiter sans.

Donc, dans le noyau, nous avons tendance à essayer d’avoir des couches génériques qui ont des mécanismes de contrôle de sécurité, le plus tôt possible. Comme ça, même s’il y a un bogue dans un système de fichiers ou dans un pilote, c’est plus difficile de rendre ce bogue exploitable. Et quand nous trouvons un débordement quelque part, nous le corrigeons et en même temps nous ajoutons (quand c’est possible) des vérifications de plus haut niveau pour empêcher qu’il ne se reproduise. C’est pour ça que dans la plupart des cas, nous finissons par corriger plusieurs trucs pour un même problème — chacun des patches aurait corrigé un truc en lui‐même, mais mis ensemble, nous espérons qu’ils seront plus résistants au cas où un problème similaire apparaîtrait ailleurs (ou soit réintroduit au même endroit — c’est embarrassant quand ça arrive, mais c’est déjà arrivé).

LinuxFr : Est‐ce que tu penses que les experts en sécurité et les créateurs d’exploitations de failles de sécurité ont une mentalité différente, si on la compare aux autres développeurs du noyau ?

Linus Torvalds : Oh, oui. Certains des « exploits » les plus intéressants m’ont fait penser que « ça nécessite vraiment un esprit tordu pour arriver à ce truc », et j’ai été carrément impressionné.

Mais il ne s’agit pas toujours d’être impressionné. Très souvent, je suis plutôt déprimé par le caractère sordide des milieux de la sécurité. C’est vraiment un cirque. Une grande partie de tout ça se réduit à des effets de manche et à des communiqués de presse (de tous les côtés : les vendeurs, les gens de la sécurité, les créateurs d’« exploits », etc.).

LinuxFr : J’ai réalisé une entrevue avec Brad Spengler (GRSecurity) et je lui ai posé une question sur son opinion à propos de toi et de la sécurité du noyau. La réponse de Brad a été : « Il peut à l’occasion comprendre les problèmes de sécurité mieux que les autres développeurs, mais la sécurité ne fait pas partie de ses buts principaux. Ses idées en ce qui concerne la sécurité ont conduit à la politique officielle des développeurs du noyau, qui est de ne pas mentionner les informations de sécurité dans les journaux des modifications (changelogs) et de traiter tous les bogues de la même façon. Ses idées sont destructrices. »
Est‐ce que tu penses que tous les bogues devraient être traités de la même façon ? Et pourquoi ?

Linus Torvalds : J’ai tendance à penser que tous les bogues devraient être traités de la même manière, et je ne veux ni signaler ni cacher nos problèmes de sécurité.

Le fait est que même les gens qui travaillent dans le domaine de la sécurité ne sont pas d’accord entre eux. Un bon nombre exige une transparence totale. D’autres veulent une transparence limitée (juste les vendeurs et les grosses institutions financières). D’autres encore veulent maintenir un secret total, à la fois pour éviter d’être embarrassés, mais aussi en partie pour éviter le risque de dissémination des infos vers les « black hats » qui écrivent des exploits.

Et il y a aussi les controverses au sujet des fuites. Tout le monde sait qu’il y a différentes sortes de « bad guys ». Cela va du type sympa qui veut juste essayer un truc (Eh, les gamins à l’université qui ont entendu parler d’un exploit et qui veulent le tester pour voir si ça ça fait vraiment tomber le gros ordinateur de leur fac), au « script kiddie » qui aime bien emmerder les autres, mais qui n’a pas nécessairement des connaissances ou des compétences impressionnantes, ou encore des gens qui sont vraiment intelligents et qui pourraient faire des trucs criminels pour gagner un maximum.

Comment est-il est possible de concilier ces points de vue divergents ? Ma position est que ce n’est pas possible.
Il n’y a pas de « réponse unique » et les gens qui essaient d’imposer leur point de vue en matière de dissémination (ou pas) de l’information font plus de mal que de bien.

Donc mon opinion personnelle est que la seule approche saine consiste à réaliser que le problème n’est pas soluble, et à juste traiter les bogues comme des bogues. On essaie en premier lieu de les éviter, mais quand ils surviennent, alors on les corrige. Et on les corrige sans crier sur les toits tous les détails sur comment écrire un exploit en partant du bogue, ou sans essayer de faciliter le boulot de ceux qui voudraient trouver des bogues à exploiter.
Oui, cela peut impliquer de ne pas dire dans le journal des modification tout ce que nous savons sur comment il est possible d’exploiter le bogue, ou même pointer vers une alerte de sécurité à son propos.

Est‐ce que les gens de la sécurité sont toujours d’accord avec moi ? Putain, non. Mais ils ne sont pas non plus d’accord entre eux, alors qu’est‐ce que ça prouve ?

LinuxFr : Est‐ce que tu as une opinion sur la qualité d’OpenBSD ? Ils mettent énormément l’accent sur la sécurité. Est‐ce qu’il y aurait des leçons à tirer de ce projet ?

Linus Torvalds : Je pense que tous les projets de système d’exploitation qui se concentrent sur un seul but sont des échecs, et cela quel que soit le but.
La sécurité en elle‐même n’est pas un but digne d’intérêt — vous avez besoin d’avoir des utilisateurs pour que la sécurité ait une quelconque importance.

Donc, je pense que la concentration exclusive sur la sécurité dans OpenBSD rend juste le projet moins intéressant et utile en définitive.

Mais là encore, il s’agit de ma mentalité générale qui consiste à penser que « les bogues sont juste des bogues ». La sécurité est importante, mais les performances aussi et les fonctionnalités également. Le monde n’est pas juste blanc ou noir. Il n’y a pas un seul truc qui soit plus important que tout le reste.

LinuxFr : Le compilateur LLVM fait de grands progrès. Qu’est-ce que tu penses de ce projet ? Est-ce que l’architecture de LLVM est meilleure que celle de GCC, et est-ce que tu penses qu’à long terme il va remplacer GCC ?

Linus Torvalds : Remplacer ? C’est possible, mais je ne pense pas que ce soit très probable. Je trouve effectivement que les compilateurs constituent un sujet intéressant, et je pense que c’est bien d’avoir un peu de compétition dans ce domaine, donc j’apprécie de voir LLVM faire cet effort.

LinuxFr : Il y a un noyau Linux dans ma box ADSL envoyée par mon fournisseur d’accès à Internet. Il y a aussi un noyau Linux dans ma télévision Sony et dans mon imprimante. Pourtant, je ne suis pas libre de « hacker » le code de ma box ADSL, de ma télévision ou de mon imprimante (du fait des raisons légales ou du fait de la « tivoisation »). Qu’est‐ce que tu penses de cette situation ?

Linus Torvalds : Personnellement, je suis d’avis que les matériels flexibles sont plus intéressants que les matériels verrouillés, mais en même temps, pour moi, la notion « d’échange équitable » a toujours été une notion liée au code et aux idées, pas au matériel.

Donc, tout mon problème au sujet de Tivo et des autres entreprises de ce type, a toujours été « Eh, ils ont conçu et construit ce matériel, le fait qu’ils aient utilisé mon code dedans ne me donne aucun droit spécifique sur ce matériel ».

Comme ils utilisent Linux, j’attends d’eux qu’ils rendent disponibles leurs patches sur le code de Linux, comme la licence l’exige. Il y a évidemment des entreprises qui ne font même pas ça, mais c’est une exception plutôt que la règle.

Donc, vous pouvez récupérer le code de Linux avec leurs modifications, et vous pouvez concevoir et construire votre propre box ADSL ou votre télévision ou tout ce que vous voulez, et utiliser toutes les améliorations de Linux qu’ils ont pu faire. Ou bien, plus important, vous pouvez utiliser leurs améliorations de Linux même si vous ne construisez pas une box ADSL — vous pouvez utiliser leurs patches sur votre desktop ou sur une machine sans aucun rapport. C’est là où les améliorations deviennent vraiment intéressantes — quand vous les utilisez pour autre chose que ce qui était prévu à l’origine.

Maintenant, bien entendu, la plupart des entreprises qui utilisent Linux dans ce domaine n’ont pas besoin de faire tant de changements que ça dans le noyau, donc il n’y a peut être aucune amélioration. C’est bien comme ça aussi. Si Linux marche pour eux sans changements, alors tout va bien. De la même manière, il marchera pour vous sans changements si vous voulez créer un matériel identique.

Donc, j’ai toujours pensé que toute cette histoire de « tivoisation » était un truc stupide. Si vous voulez faire votre propre machine Tivo, alors faites-la. Ne pensez pas que juste parce qu’elle se base sur du code open source, vous devriez contrôler le matériel. C’est de l’open source. Si vous voulez faire de l’open hardware, alors faites de l’open hardware.

Ceci dit, je pense qu’il existe de sérieux problèmes au sein de l’industrie du contenu, quand les fournisseurs de contenu utilisent la loi ou des mesures techniques de protection (MTP / DRM) pour essayer en réalité d’entraver les gens et de se créer des situations de monopole. Je n’aime pas les MTP. Mais je pense que c’est un problème différent de celui des licences de logiciels, et je pense aussi que c’était une faute grave de la part de la FSF d’essayer d’utiliser la GPLv3 comme une manière de transformer les projets des autres en armes dans leur lutte contre les MTP.
Je suis très content d’avoir rendu clair le fait que Linux est un projet uniquement GPLv2, et cela des années avant que tout ceci n’arrive.

LinuxFr : Quelle est ton opinion au sujet d’Android ? Es‐tu surtout content qu’ils aient rendu les téléphones portables très utilisables, ou bien es‐tu triste, parce qu’il s’agit en fait d’un « fork » du noyau ?

Linus Torvalds : Je pense que les forks sont une bonne chose, ils ne me rendent pas triste. Pas de mal de développement dans Linux s’est fait via des forks, et c’est la seule manière de continuer à avoir des développeurs intègres — la menace que quelqu’un d’autre puisse faire un meilleur travail et mieux satisfaire le marché en faisant les choses de façon différente. Le but même de l’open source, pour moi, est vraiment la possibilité de « forker » (mais aussi la possibilité pour toutes les parties de réintégrer le contenu qui a été « forké », s’il s’avère que c’était le « forkeur » qui avait eu raison !).

Donc je pense que le fork d’Android a obligé les développeurs de la branche principale à regarder sérieusement certains des problèmes que rencontrait Android. Je pense que nous avons résolu tout ça en mainline et j’espère (et je crois) qu’Android finira par réintégrer la branche principale. Mais cela prendra probablement un certain temps et nécessitera des efforts.

Je pense que le problème le plus sérieux, à long terme, que nous ayons actuellement dans le noyau, c’est l’incroyable prolifération sauvage du code des plates‐formes pour l’embarqué. Surtout ARM, pas parce qu’ARM est en quoi que soit fondamentalement plus délirant que le reste, c’est juste en raison du fait qu’ARM est de loin la plate‐forme qui rencontre le plus grand succès. Le monde de l’embarqué a toujours eu tendance à éviter les plates‐formes standardisées : ils avaient trop de contraintes de ressources, etc., donc ils ont conçu des puces et des chipsets sur mesure, et ils ont toujours pensé qu’ils ne pouvaient pas se permettre une trop grande abstraction de la plate‐forme.

Cela provoque pas mal de problèmes de maintenance, parce que ces plates‐formes semblent toutes un peu différentes vues du noyau, et que nous avons des quantités démentes de lignes de code, juste pour supporter toutes ces variations, alors que fondamentalement ce ne sont que des petites variations arbitraires autour d’un même truc.

Mais tout ça se produit à la fois au sein et en dehors d’Android, ce n’est en rien lié spécifiquement à Android.

LinuxFr : Qu’en est‐il des différences techniques entre Android et la branche principale ? Peut‐on résoudre la controverse autour de « wakelock » ?

Linus Torvalds : Je pense que techniquement tout est déjà largement résolu (comme dans « on doit s’occuper des détails, mais il n’y a rien de fondamentalement effrayant »), mais dans les faits, une fois que vous avez une interface et du code qui l’utilise, c’est un gros travail de faire un changement. Peut‐être qu’il n’y a pas assez de motivation pour faire ces changements rapidement. Donc, ça prendra du temps et probablement plusieurs versions (que ce soit dans la branche principale ou dans Android) avant que cela n’arrive.

LinuxFr : Windows 8 va fonctionner sur l’architecture ARM. Est‐ce que c’est une menace réelle pour la domination de Linux sur le marché de l’embarqué ?

Linus Torvalds : Ce n’est pas comme ça que je raisonne, je ne m’en préoccupe pas. Linux n’est en compétition qu’avec lui‐même, pas avec Windows. Autrement dit, du moins en ce qui me concerne, la seule chose dont je veux m’assurer, c’est que Linux s’améliore.

Cependant, je suspecte que pour arriver à gérer ARM, Microsoft va finir par exiger une certaine standardisation des plates‐formes pour les configurations qu’ils vont supporter. Cela rendra notre travail plus facile. Et je n’ai aucune objection contre ça.

LinuxFr : Peux‐tu expliquer pourquoi tu n’es pas vraiment content des patches ARM qui te sont envoyés lors de la « fenêtre d’intégration » ? Est-ce qu’il existe une solution évidente à ce problème de fragmentation ?

Linus Torvalds : Une solution évidente ? Non. Le problème, c’est la variété démentielle du matériel, et le fait que dans beaucoup de cas le code Linux des plates‐formes ARM (pas le support des processeurs ARM, juste le code de certaines puces avec tous ces problèmes de code glu autour du processeur) a souvent consisté en d’infâmes copier‐coller venant de fichiers concernant d’autres plates‐formes ARM, avec juste les modifications minimales pour permettre le support du nouveau matériel.

Et le résultat est un bordel impossible à maintenir. Tout ça devient vraiment pénible quand quelqu’un corrige un problème au cœur de l’infrastructure et que cela implique de changer des centaines de fichiers ARM différents qui utilisent tous cette infrastructure. C’est arrivé avec le boulot de nettoyage des pilotes IRQ que Thomas a effectué récemment (en fait, il a bossé là‐dessus depuis longtemps, et ce qui a été incorporé récemment, c’est juste la suppression de certaines vieilles interfaces pourries).

Cela provoque également d’autres problèmes de maintenance — les patches qui deviennent énormes —, cela signifie que les gens ne les regarderont pas d’aussi près, etc., etc.. Donc, la situation est vraiment mauvaise. La plupart de ces problèmes devraient pouvoir se résoudre en ayant de meilleures solutions génériques et en branchant dessus le code vraiment spécifique à chaque plate‐forme.

LinuxFr : Quelle est ton opinion sur les micro‐noyaux ? Est‐ce que tu continues de penser qu’ils sont un échec technique ?

Linus Torvalds : Oui, je suis toujours convaincu qu’il s’agit d’une de ces idées qui sonnent bien sur le papier, mais qui sont finalement des échecs en pratique. Parce que dans la vraie vie, la complexité se trouve dans les interactions, pas dans les modules individuels.
Et les micro‐noyaux s’efforcent de rendre les modules encore plus indépendants, ce qui rend les interactions encore plus compliquées et indirectes. Cette séparation aboutit au fait de supprimer pas mal de canaux de communication qui sont simples et évidents.

LinuxFr : Et à propos des systèmes d’exploitation à code géré (managed code), comme Singularity ? Est‐ce que c’est plutôt un projet de recherche, ou bien penses‐tu que ça peut vraiment marcher ?

Linus Torvalds : Moi, je suis plutôt du genre dur et pragmatique. À l’heure actuelle, cela ressemble uniquement à un projet de recherche. En fait, le diable est dans les détails. Un bon paquet de ces merveilleux projets théoriques de nouveaux environnements se contentent d’évoquer des grandes idées générales, et ne parlent pas de tous les petits détails dont vous devez prendre soin quand vous avez des tas d’utilisateurs bien allumés qui font des trucs bizarres et merveilleux.

En fait, je n’en vois pas l’intérêt. Les systèmes d’exploitation ne sont pas si compliqués que ça, après tout. Il n’y a rien de fondamentalement mauvais dans le modèle UNIX. C’est vrai, nous avons beaucoup de code et je ne prétends pas que ce code est simple, mais c’est parfaitement possible à gérer. Les plus gros problèmes que nous ayons, concernent surtout le support des pilotes et des plates‐formes — et ces trucs ne se règlent pas avec des nouveaux modèles de programmation.
Les micro‐noyaux ou les systèmes d’exploitation en code géré ? Cela ne résout aucun des grands problèmes que je connais.

LinuxFr : Imagine que nous sommes en 2031 et que le noyau Linux a maintenant quarante ans. Es‐tu toujours le leader du projet ? Penses‐tu que le noyau est toujours plus ou moins le même qu’en 2011, ou bien de nouvelles innovations radicales ont‐elles été incluses ?
/troll mode: Est‐ce que le noyau a été réécrit en C++ ?

Linus Torvalds : J’espère vraiment, vraiment, qu’en 2031 nous aurons dépassé le stade où le système d’exploitation est le lieu approprié pour les idées radicales. C’est clair que les machines auront toujours un système d’exploitation, et j’espère que ce sera Linux, mais il vaudrait mieux que tout le travail radical et intéressant soit fait en espace utilisateur, afin de nous permettre d’interagir de façon plus excitante avec toute cette puissance de calcul.

Donc, à titre personnel, je pense que le modèle du noyau sera toujours valide — et que les changements se situeront à un niveau différent.

Après tout, nous avons eu quarante ans avec Unix, et toute l’approche du type « noyau monolithique en C » n’est pas devenue invalide au cours de ces quarante années. Oui, les détails ont changé, le langage a évolué, et nous avons des interfaces bien plus complexes. Mais la conception de base est encore tout à fait reconnaissable. Je ne pense pas que vingt ans de plus vont nécessairement changer tout ça.

LinuxFr : Eh bien, merci beaucoup Linus pour tes réponses aux questions… Et, bon anniversaire au noyau ! ;-)

Aller plus loin

# Original version

Posté par patrick_g (site web personnel) le 03 mai 2011 à 21:00. Évalué à 10. Dernière modification le 15 novembre 2011 à 16:56.

LinuxFR : You've been doing Linux for about 20 years now and it's a hard job. Is it still fun ?

Linus Torvalds : Oh, absolutely. It's still fun. And partly exactly because I've been doing it for 20 years, I wouldn't call it "hard". It's still challenging and interesting, but I think I'm good at it.

LinuxFR : Why did you choose to switch the kernel from his original non-GPL copyright to the GPL licence ? Was it an ethical or a practical choice ?

Linus Torvalds : Practical. I think my original license contained the ethical parts I cared about, but it turns out that it was too strict about that whole "no money" thing, and it also wasn't well enough known. Moving to the GPL fixed the problems that people had with my original license, and had the advantage that it was a known entity and also a lot more likely to stand up in court than the short blurb I had written originally.

LinuxFR : I know that you consider yourself a very pragmatic person and not a prophet...but do you agree that there is an ethical content in the GPL license ?

Linus Torvalds : I'll answer this two very different ways, and try to explain why I answer it two ways.

So the first and the very negative answer is that I absolutely despise the people who try to push the GPL as being about "ethics".
I think that's absolute bullshit. Why? Because ethics are to me something private. Whenever you use it as an argument for why somebody_else should do something, you're no longer being ethical, you're just being a sanctimonious dick-head.

But the second answer is that I personally feel that the GPL (version 2) matches what I want to do. I really like doing programming, and I wanted to put my stuff out there for others to enjoy, but I felt that the whole "you can do with it as you wish, but your improvements need to be available the same way the original is available" is just very fair, and is a great way to do development.

So personally I think the GPLv2 matches quite closely what I think is "the right way to live my life". And by "right way" I don't think it's the only way. I've done commercial programming too, and I enjoyed that a lot, and I think that was fair and appropriate too (hey, they paid me for it).

So I think the GPLv2 is a great license, and I use it for my own personal reasons. I do think that's true of a lot of other people too, but I really want to point out that it's not that the license is somehow ethical per se. A lot of other people think that the BSD license with its even more freedoms is a better license for them. And others will prefer to use a license that leaves all the rights with the original copyright holder, and gives no rights to the sources at all to others. And for them, that is their answer. And it's fine. It's their choice.

Trying to push any particular license as "the ethical choice" just makes me mad. Really.

LinuxFR : Why is the desktop so special and so much harder than any other market ?

Linus Torvalds : Because it's so much more interesting. It's the market where people do so many different things.

Your average server does almost nothing. Sure, it may have a lot of CPU power, a fast network, and lots of IO, but it does the same thing over and over again, and that "same thing" is pretty limited. It's running a database, a mail or web server, various analytics etc. It may be important for the company, but it's not a very varied workload,
and it's not something people are attached to.

In contrast, your desktop is what you see every day, and you get attached to it. The attachment might be some kind of "stockholm syndrome" where you really don't necessarily like it (think of all the people who grew to know computers through DOS and Windows, and the three-finger ctrl-alt-del salute), but even then it becomes a kind of dependency where you get used to it and rely on it rather more intimately than you ever end up relying on the company mainframe.

And the desktop does so much more. You play games on it, you do word processing on it, you do development on it. It's not a single-trick pony. Of course, for some people it has also become "you use a web browser on it" and nothing much more, but even that single use tends to in many ways be a more complex workload than most server workloads.

Of course, what's interesting is how smartphones are slowly starting to share many of those desktop complexities. It may not be there yet (and maybe it never will be), but phones already have a fair amount of the same rich and complex media issues that desktops have, and are getting more varied uses.

LinuxFR : Why Linux desktop hasn’t been adopted by the mainstream users ? Is it possible for the kernel community to improve this situation or is it mostly a user space problem ?

Linus Torvalds : I don't think there's much we can do on the kernel side, except continue to improve in general, and make sure we remain the technically best choice.

And it's not really that we don't have mainstream users - Android is an example of lots of mainstream users for Linux. The problem is that the desktop is a difficult market to reach. There are huge amounts of "network effects" where having existing users is a big reason to retain them and get more new users. It's also that most people really
really don't want to change their environment, and if they do switch, they want help and support. Where "support" is not necessarily about commercial support, it's about knowing that you have people around you who know the system and can give you advice etc.

Getting past that hump is hard. And it's not something that happens by pointing at technical issues. It's often a social issue.

LinuxFR : I know it's a strange (and probably dumb) question but are you still able to fully understand all parts of Linux kernel or do you really need trusted maintainers ? For example concerning the complex pathname lookup patchs from Nick Piggin what was your process to choose between these patchs and the other solution from Dave Chinner ? Have you received some advices from Al Viro or was it your lone decision ?

Linus Torvalds : Oh, I absolutely don't claim to know and understand all of the kernel. I know a wider chunk of it than most kernel developers, but there are many areas where I almost entirely rely on the maintainers, because I just don't know (or necessarily even care - we all have our own areas of interests) enough about some subsystem.

That said, the example you picked wasn't one of those areas. The VFS layer and most of the VM layer I'm intimately familiar with, and so I had no problems feeling like I could make those decisions on my own, and support the end result even without further help. Of course, that's not to say that I didn't expect people like Al to help me, and
I didn't talk it over with them, but when it came to the new pathname lookup, I was much more personally involved than I am in most other areas.

Of course, usually I don't really want to feel like I need to be personally involved. The pathname patches had been around for most of a year, and weren't making much progress (there was a lot of discussion, but not as much forward progress as I wanted), so I ended up championing those patches a bit more than I would necessarily
otherwise have done. I'd have been perfectly happy having them go entirely through the normal submaintainer channels.

In some other cases, I can't do that kind of "I'll step in and make some executive decision", because I don't necessarily know the area well enough, or I don't feel like I can really end up maintaining the end result if I really piss off the maintainer too badly. So then I can prod and try to raise discussion about issues, but I'll just have
to trust that somebody gets up and makes the right decision.

(Btw, "right decision" is not necessarily the right word. Sometimes you just need to make a decision. It's not always clear what the "right" answer is, and sometimes it's fine to just say "we don't know" and not make a decision at all. But at other times you really do need to make some kind of technical choice. The good news is that most
technical choices can be reversed if they turn out to be wrong later on - it may be very painful, but sometimes it's better to just make a choice even if you can't know whether it's the right one. Even if there is a chance that you may have to reverse that choice later)

I should say that those kinds of situations are actually pretty rare. Most of the time the development process works without anybody having to make particularly difficult choices. Most of the time it's fairly clear that the forward direction is, and sometimes it's just hard to find people that actually write the code :)

LinuxFR : What do think about this citation from Lennart Poettering ? : "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!"

Linus Torvalds : Well, I think it can be a reasonable way to simplify a very difficult problem (portability).

But one reason it's likely to be a good way is that we really don't try to extend too much - and not unnecessarily - on the standard interfaces, so even if you do end up deciding to just care about Linux, it's really hard to make the end result horribly unportable. Linux is a pretty middle-of-the-way UNIX in many respects, and even
outside of the unixes, most of the frameworks that you'd use on Linux are available on other platforms too (often because they are open source).

So even if you later decide that you do want to be portable after all, going with Linux to begin with was probably not a bad idea, and it may have simplified the early decision process in a project.

LinuxFR : Do you think systemd is a huge improvement in comparison to SysV init ? Is it a game changing technology ?

Linus Torvalds : I also will take a somewhat wait-and-see approach, it's not widely enough used yet. I do think bootup performance is important, and anything that helps that, and helps make it more flexible is a good thing. Would I call it "game changing"? Probably not.

LinuxFR : Do you use btrfs ? When do you think it will be ready to replace ext4 as the default recommended file system ?

Linus Torvalds : I've used btrfs on a couple of the laptops I have, but honestly, when it comes to filesystem usage, the big factor is distribution support. Almost nothing else matters, as long as the core capability is there. So getting a distribution to pick a filesystem by default is the way it ends up being the commonly recommended one, simply because what most people care about in filesystems is neither features nor performance, but stability.

And me personally, I don't worry about it any more. I had some issues with ext3 (horrible fsync performance in particular), but most of what I do is actually totally dominated by the VFS layer, because it caches so well (ie I have the kernel sources in memory pretty much all the time, and the filesystem doesn't matter because all the caching is
done by generic routines).

LinuxFR : With Linux and Git you've done two softwares that changed the computer world. How is it possible to have two gigantic success like these ? What is the difference between you and mere mortals ?

Linus Torvalds : I think a lot of it is just stubborn persistence. Especially Linux - I was in the right place at the right time, but others could have done their own operating system. And others did. But very few people ended up just doing it as much as I did. I've been at it for twenty years. Most developers doing some random private project for their own enjoyment don't stay with it long enough for it to ever be even release ready. Much less for decades.

With git, things were a bit different. Partly because I had a use case that was big enough (the kernel) that I could jump-start it, but partly because I really came at an old problem from a new angle, and I do think I did a good job as "architect" for the project. I really think that git has a fundamentally good design (in the case of Linux I
could just build on top of the design of Unix that had already been done), and I could push it through because Linux needed more than the existing SCM projects could offer.

But with git, a lot of the credit really does go to Junio Hamano. He's really been a great maintainer. People like that are important. Yes, open source programming is a team sport, but finding the right people is really the killer feature (the same is obviously true in the kernel too - I really do think we have a great set of maintainers. I may
complain about them and I'm somewhat infamous for my flames when things don't work, but at the same time I'm convinced there's some of the best people out there working on maintaining the kernel).

LinuxFR : I've seen that you read a lot about biology and evolution theory (for example Richard Dawkins). Is that knowledge useful for Linux process developpement ? Is it mostly a darwinian competitive model or a cooperative one ?

Linus Torvalds : I don't think it's useful for the kernel, but it does happen to be a subject I'm interested in. Biology, evolution, human behavior - they are all fascinating subjects. And I think there are parallels between technological development and evolution. I obviously do not believe in Intelligent Design when it comes to biology (and I think anybody who does is woefully badly educated), but after all, I often think that "intelligent design" is much overrated in technology too. Many technical improvements really do seem to be about more "organic" developments, and very few are fully designed ahead of time. In fact, I think most interesting technical problems are too complicated to "design" for - the way you get to a solution is very much through incremental improvements and trial and error.

LinuxFR : You are now an american citizen. What do you think about software patent law in USA ? Is your voice strong enough to help fight this law in this country ?

Linus Torvalds : I have to admit that while I don't like patents, I also tend to try to stay away from getting too involved in issues like those. I'm good at what I do, I think there are people who are better at fighting the patent mess. And I think you need to do so from within the system - so I'd expect that any solution will actually largely come from all the companies who are being hurt by the mess that it is.

LinuxFR : You often wrote detailled posts on realworldtech.com but I've never seen a post from you on lwn.net. Why ? Do you read lwn.net regularly ?

Linus Torvalds : Heh. rwt is where I go to flame people and argue about computer architecture. I like people who argue back, and I also like how it's not Linux people, or even about Linux. So I can spout my opinions and see what arguments I can get to happen.

lwn? That would be an entirely different kettle of fish.

LinuxFR : Various people criticized kernel security. Do you think kernel devs put enough work on kernel security mechanisms and code review ? Do you think some parts of GRSecurity should be imported in mainline ?

Linus Torvalds : I think we've done a pretty good job, but one of the problems with the security world is that it's so black-and-white. To some security people, even me just saying "pretty good job" is like a red flag. They don't think "pretty good" is good enough, they think security is somehow everything.

And I disagree. Most security problems are just bugs. We need to try to avoid bugs, but bugs happen. That's a truism, but I think it's what it all boils down to. Are we better at avoiding bugs than other projects? I think we're doing pretty well, especially considering just the insane amount of code we write and change every single day. I really don't think it's useful to try to separate "security bugs" from other bugs. They're all just bugs, and almost any bug could be a security bug under the right circumstances.

As to grsecurity, I think we've taken the important things, and left the extreme things (the ones that actually hinder usability or are otherwise extremely intrusive) behind.

In general, the best way to security tends to be to have many different layers of security. You can never be entirely bug-free in any half-way interesting program, but with multiple layers of security, one layer will hopefully end up protecting against the possibility of a bug at another layer that might otherwise have resulted in an exploit.

So in the kernel, we tend to try to have the generic layers already have security checks early, so even if there's a bug in a filesystem or a driver, it's harder to cause that bug to be exploitable. And when we do find some overflow, we tend to fix both the immediate overflow itself as well as (when possible) add checks at higher levels so that the overflow couldn't have happened in the first place. So in many cases we actually end up with several fixes to the same problem - each of which would have fixed things on its own, but together they end up hopefully being more resistant to a similar problem happening somewhere else (or later be re-introduced in the same place - it's embarrassing when it happens, but that has happened too).

LinuxFR : Do you think security experts and exploits creator have a different mindset compared to other kernel developpers ?

Linus Torvalds : Oh yes. Some of the more interesting exploits in particular have made me go "that needs a really twisted mind to come up with" and being quite impressed.

But it's not always about being impressed. Quite often I get rather depressed by all the sleaze in security circles. It really is a circus. A lot of it is all about posturing and PR (on all sides:vendors, security people, exploiters etc).

LinuxFR : I've done a interview with Brad Spengler (GRSecurity) and asked a question about his opinion on you and kernel security. Brad's answer was: "He at times can understand security better than some of the other developers, but security isn't one of his main goals (...) His ideas regarding security that have formed the official policy of kernel developers to omit security-relevant information in changelogs and treat all bugs the same are destructive".
Do you think all bugs should be treated the same ? And why ?

Linus Torvalds : I tend to think that all bugs should be treated the same, and I neither want to point out, nor particularly hide our security issues.

The thing is, even security people cannot agree. Many of them want full disclosure. Others want very limited disclosure (vendors and big financial institutions). Others want just total secrecy, both to avoid embarrassment, but also at least to some degree to avoid the issue leaking to the "black hat" people who write exploits.

And then there's the fights about leaks - everybody knows that there are different classes of "bad guys", ranging from just regular good people who want to try things out (hey, university kids who hear about a new exploit, and decide that they want to test whether the big university machines really do crash) to script kiddies who like being annoying but don't necessarily have all that impressive technical background and understanding, to people who are really smart and may well be doing things for serious criminal gain.

How the hell do you resolve those discussions? I claim that you can't. There is no "right way", and the people who push their way of doing disclosure (or not) are demonstrably doing bad things.

So my personal opinion is that the only sane approach is to just realize that it's not a solvable issue, and just treat bugs as bugs. We try to avoid having them in the first place, but when they do happen, we fix them. And we fix them without shouting from the rooftops about the details about how to exploit the issue, and without even trying to make it easy for the people who might want to try to exploit things to find them. And yes, that can very much involve not saying everything we know about how to exploit the bug in the changelog, or even necessarily pointing out that there is an advisory about it.

Do security people always agree with me? Hell no. But they don't agree amongst themselves either, so what does that prove?

LinuxFR : Do you have an opinion on OpenBSD quality ? They put strong emphasis on security. Is there some lessons to learn from this project ?

Linus Torvalds : I think that any single-purpose OS project is a failure, and it doesn't matter what the purpose is. Security on its own is not a worthy goal - you need to have users for security to even matter in the first place.

So I think the single-mindedness about security in OpenBSD just makes the whole project less interesting and relevant in the end.

But again, that's just my general "bugs are bugs" thinking. I think security is important, but so is performance, and so are features. The world just isn't black-and-white. There is no one single thing that matters more than other things.

LinuxFR : LLVM compiler is making huge progress. What do you think about this project ? Is LLVM architecture better than GCC and do you think it will replace GCC in the long run ?

Linus Torvalds : Replace? Might happen, but I don't think it's particularly likely. I do find compilers interesting, and I think it's good to have some competition in that area, and so I like seeing LLVM make the effort.

LinuxFR : There is a Linux kernel on my ADSL box sent by my Internet service provider. There is also a Linux kernel on my Sony TV and on my printer. However I'm not free to hack on my ADSL box, my TV or my printer (due to legal reasons or due to tivoization). What do you think about this situation ?

Linus Torvalds : I personally think flexible hardware is more interesting than locked down hardware, but at the same time, to me the "fair exchange" was always about the software and the ideas, not about hardware.

So my whole issue with Tivo and company has always been "hey, they designed and built the hardware, the fact that they used my software doesn't give me any special rights to the hardware".

Since they are using Linux, I do expect them to make their changes to Linux source code available to people as the license requires. There obviously have been cases of companies not doing even that, but that's the exception rather than the rule.

So you can take that Linux source code with their modifications, and design and build your own ADSL box or TV or whatever and use whatever improvements to Linux that they did. Or more relevantly, you can use their Linux improvements EVEN IF YOU DON'T make an ADSL box - you can do it on your desktop, or on some totally unrelated computer, and that's when the improvements become rally interesting - when you use them for something else than they were originally meant for.

Now, of course, most Linux users in that space don't actually need to make all that many changes to the kernel, so there may not be any improvements. That's fair too. If Linux worked for them without modifications, then that's fine. Again, it will work for you without modifications if you want to do some similar hardware.

So I always thought the whole "Tivoization" thing was silly thing. If you want to make your own Tivo, just do it. Don't think that just because it runs open source you should control the hardware. It's open source. If you want to make open hardware, make open hardware.

Now, that said, I do think that there are serious problems in the content industry, where content providers are using laws and technical measures to basically try to lock people in and create more of a monopoly situation. I don't like DRM. But I think that's a different issue from the software license, and I also think that it was seriously wrong of the FSF to try to use the GPLv3 as a way to make other peoples software projects into weapons in their fight against DRM. And I'm very happy that I had made it clear that Linux was a GPLv2-only project many years before that all happened.

LinuxFR : What is your opinion about Android ? Are you mostly happy they made cellphones very usable or sad because it's really a kernel fork ?

Linus Torvalds : I think forks are good things, they don't make me sad. A lot of Linux development has come out of forks, and it's the only way to keep developers honest - the threat that somebody else can do a better job and satisfy the market better by being different. The whole point of open source to me is really the very real ability to fork (but also the ability for all sides to then merge the forked content back, if it turns out that the fork was doing the right things!)

So I think the android fork forced the mainline developers to seriously look at some of the issues that android had. I think we've solved them in mainline, and I hope (and do think) that android will eventually end up merging to mainline. But it will probably take time and further effort.

I think the more serious long-term issue we have in the kernel is the wild and crazy embedded platform code (and mostly ARM - not because ARM is in any way fundamentally crazier, but because ARM is clearly the most successful embedded platform by far). The embedded world has always tended to eschew standardized platforms: they've been resource constrained etc, so they've done very tailored chip and board solutions, and felt that they couldn't afford a lot of platform abstraction.

That causes a big maintenance headache, because then all those crazy platforms look slightly different to the kernel, and we have all that silly code just to support all those variations of what is really just the same thing deep down, just differently hooked up and with often arbitrary small differences.

But that's something that happens both within and outside of Android, it's in no way android-specific.

LinuxFR : What about the technical differences between Android and mainline ? Do you think the "wakelock" controversy is solvable ?

Linus Torvalds : I think it is technically largely solved (ie "details to be fixed, but nothing fundamentally scary"), but practically once you have an interface and existing code, it just is a fair amount of work to change. And there perhaps isn't quite enough motivation to make those changes very quickly. So it will take time, and probably several releases (both mainline and adroid) to actually happen.

LinuxFR : Windows 8 will run on ARM. Is this a real threat to Linux dominance on embedded market?

Linus Torvalds : It's not how I think, or care. Linux competes with itself, not with Windows. IOW, at least as far as I'm concerned, the thing I want to make sure is that Linux just improves.

If anything, I suspect that in order to support ARM, MS will end up forcing some platform standardization on the ARM setups they support, and will make our job easier. I won't mind that at all.

LinuxFR : Can you explain why you're not happy with the ARM patches sent to you during merge windows ? Is there an obvious solution for this fragmentation problem ?

Linus Torvalds : Obvious solution? No. The problem is the wild variety of hardware, and then in many cases the Linux ARM platform code (not the ARM CPU support, but the support for certain chips with all the glue issues around the CPU core) has been mostly ugly "copy-and-paste" from some previous ARM platform support file, with some minimal editing to make it match the new one.

And it just results in this unmaintainable mess. It becomes painful when somebody then fixes some core infrastructure, and you end up with a hundred different ARM files all using that infrastructure. That happened with the IRQ chip driver cleanups Thomas did recently (well, has been doing over along time, the recent part is really just the final removal of some nasty old interfaces).

It results in other maintainability issues too - patches being big just means that people won't look at them as carefully etc etc. So it's just a bad situation. Many of the cases should be solvable by having better generic solutions and then plugging in just some per-platform numbers for those solutions.

LinuxFR : What is your opinion about microkernels ? Do you still think it's a technical failure ?

Linus Torvalds : Yes, I'm still convinced that it's one of those ideas that sounds nice on paper, but ends up being a failure in practice, because in real life the real complexity is in the interactions, not in the individual modules.

And microkernels strive to make the modules more independent, making the interactions more indirect and complicated. The separation essentially ends up also cutting a lot of obvious and direct communication channels.

LinuxFR : What about managed OS like Singularity ? Is it research only or do you think it can work ?

Linus Torvalds : I'm a rather harsh and pragmatic person. Right now it looks like research only. The devil really is in the details, and a lot of these nice theoretical frameworks talk about the big issues, but not about all the details that you hit when you have all those crazy users that do odd (and wonderful) things.

And the thing is, I really don't see the point. Operating systems aren't that complicated. There's nothing wrong with the UNIX model. Sure, we have a lot of code, and I'm not claiming it's simple code, but it's quite manageable. The biggest problems we tend to have in Linux is driver and platform support - not things that are fixed with some new programming model. Microkernels or managed code? They really solve none of the big problems I see.

LinuxFR : Imagine we're in 2031 and the Linux kernel is now forty years old. Are you still the project leader ? Do you think the kernel is more or less the same than in 2011 or do you think there are new radical innovations included ?
/troll mode: Was it rewritten in C++ ?

Linus Torvalds : I really really hope that by 2031, we'll have moved past the OS as a place for radical ideas. Sure, it will run some OS, and I hope it will be Linux, but all the radical and interesting work had better be done in user space and in giving us more exciting interfaces to the computing power.

So I personally do think that the kernel approach will still be valid and that the changes will be at a different level.

After all, we've had forty years of Unix, and that whole "monolithic kernel in C" hasn't become invalid in those forty years. Sure, the details have changed, the language has evolved, and we have way more complex interfaces, but the basic design is still quite recognizable. And I don't think another 20 years will necessarily change that at all.

LinuxFR : Thanks a lot for your answers...and happy birthday for the kernel :-)
- [^] # Re: Original version
  
  Posté par Thom (site web personnel) le 04 mai 2011 à 00:24. Évalué à 10.
  
  Une Interview très intéressante et instructive. Merci.
  
  La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
  - [^] # Re: Original version
    
    Posté par JGO le 04 mai 2011 à 09:27. Évalué à 10.
    
    Bravo également aux traducteurs, la version française est d'une qualité remarquable.
- [^] # Re: Original version
  
  Posté par Nicolas Legrand (site web personnel) le 04 mai 2011 à 14:21. Évalué à 1.
  
  Single-purpose OS? Hum... http://www.undeadly.org/cgi?action=article&sid=20110420080633
# Enfin une interview intéressante

Posté par Amaury le 03 mai 2011 à 21:58. Évalué à 10.

Merci à ceux qui ont sélectionné les questions à poser : sans être révolutionnaire, cet interview change agréablement des questions "madame Michu découvre linusque" qu'on peut voir en général.
Donc merci, et merci aussi à Linus qui a du passer pas mal de temps à répondre (Linus, si tu nous lis...).
# Windows et Linux ne sont pas en compétition

Posté par Xavier Teyssier (site web personnel) le 03 mai 2011 à 21:58. Évalué à 10.

Linux n’est en compétition qu’avec lui‐même, pas avec Windows.

Remarque pleine de bon sens, avec laquelle je souscrit pleinement !
Et si plus de monde réagissait de la même manière, certaines discussions seraient franchement plus simple.
- [^] # Re: Windows et Linux ne sont pas en compétition
  
  Posté par B16F4RV4RD1N le 04 mai 2011 à 00:10. Évalué à 10.
  
  Linux n’est en compétition qu’avec lui‐même
  
  On comprend mieux maintenant pourquoi ils changent les API tous les 4 matins...
  
  Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
  - [^] # Re: Windows et Linux ne sont pas en compétition
    
    Posté par reno le 04 mai 2011 à 13:27. Évalué à 10.
    
    API internes à Linux, pas les API externes..
- [^] # Re: Windows et Linux ne sont pas en compétition
  
  Posté par batousky le 04 mai 2011 à 08:16. Évalué à 5.
  
  Linux en tant que noyaux n'est pas en compétition avec windows. Pour une distribution c'est différent, ils visent le même publique, ils sont en compétition. Enfin tout dépend de la distribution, Ubuntu est clairement en compétition avec windows. Gentoo par exemple est plutôt en compétition avec d'autres distributions, plus généralement tout se qui s'éloigne de l'OS pour Mme Michu, ne cherche pas à rivaliser avec windows et n'est donc pas en compétition avec.
  
  Enfin c'est se que je pense
  - [^] # Re: Windows et Linux ne sont pas en compétition
    
    Posté par Sytoka Modon (site web personnel) le 04 mai 2011 à 09:49. Évalué à 6.
    
    Ubuntu me semble plus en compétition avec MacOC X à l'heure actuelle qu'avec Windows.
    - [^] # Re: Windows et Linux ne sont pas en compétition
      
      Posté par B16F4RV4RD1N le 04 mai 2011 à 10:09. Évalué à 10.
      
      Gnome3 aussi, ils ont réussi d'ailleurs à rendre cela encore moins ergonomique que mac os x
      
      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# wouah

Posté par Tof le 03 mai 2011 à 22:01. Évalué à 7.

Ce type est un putain de génie.

Merci pour cette interview, les questions sont parfaites.
- [^] # Re: wouah
  
  Posté par kowalsky le 04 mai 2011 à 11:00. Évalué à 7.
  
  Je pense que l'on peut plutôt parler de Dieu !
  
  En effet, plusieurs milliers (millions même je pense) de personnes passent leur journée à contempler béatement, en tripatouillant un clavier, le regard fixe et perdu, le résultat de son travail.
  
  Moi même, d'ailleurs, au moment ou j'écris ces mots...
# Naavi Linux :-)

Posté par bubar🦥 (Mastodon) le 03 mai 2011 à 22:03. Évalué à 10.

Et Merci DLFP de cette interview. Tout y est lumineux :)
- [^] # Re: Naavi Linux :-)
  
  Posté par bubar🦥 (Mastodon) le 03 mai 2011 à 22:11. Évalué à 9.
  
  Cette entrevue va t elle rester jusqu'à la fin de l'année en bandeau de première page. (Au moins jusqu'à septembre ?)
# Torvalds vs Stallman

Posté par CHP le 03 mai 2011 à 22:37. Évalué à 10.

Quel bonheur de lire cette interview du père de notre noyal préféré ! Surtout quand on compare aux interview de RMS ! Pas de discours moralisateur, pas de "c'est de votre liberté dont il s'agit, donc aucun compromis n'est possible". Linus est pragmatique, et surtout, il n'essaye pas de convertir les gens ni d'imposer ses idées. Il ne fait que les exposer, libre à chacun d'adhérer ou pas. J'adore ce type !

l’éthique, pour moi, c’est quelque chose de privé. Chaque fois que vous l’utilisez dans un argument pour dire pourquoi quelqu’un d’autre devrait faire un truc, alors vous n’êtes plus éthique. Vous devenez juste une tête de con moralisatrice.

Une phrase pleine de bon sens, dont beaucoup de personnes (j'en fait parfois partie) devraient s'inspirer. Et toujours ce meme franc-parler qui fait plaisir.

Linus, merci à toi ! Je t'aime d'amooouuuur !

Merci également à l'equipe de linuxfr.org pour cette interview très interessante.
- [^] # Re: Torvalds vs Stallman
  
  Posté par Grunt le 04 mai 2011 à 00:17. Évalué à 10.
  
  Ouais, enfin le passage sur la tivoïsation est un peu brutal.
  
  Vous achetez un matériel, vous en êtes propriétaire, vous ne pouvez pas en faire ce que bon vous semble? Linus vous conseille d'acheter un fer à souder et des pièces détachées. Mouais. C'est un point de vue un peu radical.
  
  Je me demande comment lui se serait démerdé pour créer son noyau dans les conditions de maintenant, c'est à dire avec du matériel fermé de partout.
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
  - [^] # Re: Torvalds vs Stallman
    
    Posté par insert_coincoin le 04 mai 2011 à 00:48. Évalué à -1.
    Oui, je ne comprends pas sa position :
    - un logiciel est sous gpl
    - un constructeur utilise, modifie et redistribue ce logiciel avec son matériel
    - ce même constructeur ne distribue pas les modifications du code source
    - donc il ne respecte pas la licence gpl
    Là on a le droit de gueuler, non ? C'est pas une question de contrôle du matériel, comme le dit Linus, mais bien une question de contrôle du logiciel ! Personne ne remet en cause le fait que le matériel soit fermé et que si on veut bricoler il va falloir transpirer un peu (c'est l'jeu ma pauv' Lucette), mais dans la mesure où le code modifié devrait être accessible, il faut qu'il soit accessible.
    - [^] # Re: Torvalds vs Stallman
      
      Posté par bubar🦥 (Mastodon) le 04 mai 2011 à 02:27. Évalué à 7.
      
      Linus dit grosso modo "presque ok à la tivoisation", et ce, sur une deux phrase, et argumentées. C'est bien clair, bien expliqué. Et il insiste sur deux phrases longues, constituant chacune un paragraphe. Enfin, il revient dessus pendant trois longs paragraphes. Dont un lui permettant de rebondir la gpl v3, et de valider son choix de v2, donc la limite (il revient un peu dessus en causant bsd, d'une certaine manière, sur ce point de vue là)
      
      Et au milieu, que trouve t on ? un clair "j’attends d’eux qu’ils rendent disponibles leurs patches" (...) "comme la licence l’exige." (...) [certains] "qui ne font même pas ça, mais c’est une exception plutôt que la règle." Voilà.
      
      Typique de son discours pragmatique que l'on retrouve dans d'autres tournures. Et tout en finesse, le "c'est une exception" genre "peu nombreux, ils vont entrer dans le rang et respecter la licence".
      
      C'est efficace. Non ?
    - [^] # Re: Torvalds vs Stallman
      
      Posté par Matthieu Moy (site web personnel) le 07 mai 2011 à 13:10. Évalué à 6.
      Ce n'est pas ça la tivoisation. Distribuer un binaire de Linux modifié sans distribuer les sources, c'est interdit par la licence, que ce soit GPLv2 ou GPLv3. La tivoisation, c'est :
      
      Un logiciel est sous GPL
      
      Un constructeur distribue ce logiciel (ou une version modifiée) sur une plateforme matérielle fermée
      
      Légalement, tu peux modifier le logiciel, mais techniquement, si tu le fais, le matériel refuse de l'exécuter.
      
      Linus ne dit pas que c'est bien, il dit que ce n'est pas l'affaire du logiciel de s'occuper de ça.
      - [^] # Re: Torvalds vs Stallman
        
        Posté par claudex le 07 mai 2011 à 14:44. Évalué à 2.
        
        mais techniquement, si tu le fais, le matériel refuse de l'exécuter.
        
        Uniquement si tu essaye de mettre le logiciel modifier sur le matériel.
        
        →[]
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Torvalds vs Stallman
    
    Posté par Elfir3 le 04 mai 2011 à 12:16. Évalué à 5.
    
    Je me demande comment lui se serait démerdé pour créer son noyau dans les conditions de maintenant, c'est à dire avec du matériel fermé de partout.
    
    Simple, tu le dis toi même... fer à souder, transistors, circuit imprimé, un coup de fil à chuck, et hop, un octo-core !
  - [^] # Re: Torvalds vs Stallman
    
    Posté par reno le 04 mai 2011 à 13:37. Évalué à 4.
    
    Ouais, enfin le passage sur la tivoïsation est un peu brutal.
    
    Brutal? Curieux comme qualificatif, en tout cas ce n'est pas nouveau:
    il avait déjà exprimer cet avis lors de l'élaboration de la GPLv3 (l'interdiction de la tivoïsation est une des choses qu'il n'aimait pas dans la GPLv3).
    
    Vous achetez un matériel, vous en êtes propriétaire, vous ne pouvez pas en faire ce que bon vous semble? Linus vous conseille d'acheter un fer à souder et des pièces détachées. Mouais. C'est un point de vue un peu radical.
    
    Bof et si le constructeur du matériel met le code dans un ROM, tu feras quoi?
    La tivoïsation est une variante de ça..
    
    (coupé) dans les conditions de maintenant, c'est à dire avec du matériel fermé de partout.
    
    Ahem, les PCs sont toujours aussi ouvert qu'il l'étaient auparavant.
    OK, il y a certains matériels qui sont fermés, mais dire que le matériel est fermé partout me parait une grosse exagération.
    - [^] # Re: Torvalds vs Stallman
      
      Posté par claudex le 04 mai 2011 à 13:48. Évalué à 8.
      
      Bof et si le constructeur du matériel met le code dans un ROM, tu feras quoi?
      La tivoïsation est une variante de ça..
      
      Par vraiment, la ROM, c'est une vrai barrière, ça empêche aussi le constructeur de mettre à jour. La tivoïsation, c'est une limite totalement artificielle.
      
      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
      - [^] # Re: Torvalds vs Stallman
        
        Posté par Grunt le 04 mai 2011 à 17:09. Évalué à 8.
        
        Exact, c'est toute la différence entre "ça n'a pas été conçu pour être bidouillé" et "ça a été conçu pour ne pas être bidouillé."
        
        Linus évolue dans un monde où les choses sont, au pire, "pas conçues pour être bidouillées", il a du mal à comprendre que des gens se heurtent à des barrières artificiellement mises en place par des crétins pour faire chier le monde (Désolé, mais bon voilà).
        
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par Gniarf le 04 mai 2011 à 19:54. Évalué à 7.
        
        c'est pas forcément des crétins, hein, ça peut être des gus très intelligents mais qui le font exprès
        
        hein Steve ?
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par GTof le 05 mai 2011 à 14:32. Évalué à -7.
        
        On peut être en même temps excessivement intelligent et crétin. Linus nous en donne d'ailleurs un très bon exemple concernant son avis sur la sécurité, la liberté, ... Il est tellement borné à ne voir que le coté technique que sur le reste, quel crétin!
        
        Et chapeau pour l'interview, excellentes les questions!
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par Michel Nicolas (site web personnel) le 07 mai 2011 à 11:18. Évalué à 10.
        
        Je pense que son point de vue sur la tivoisation est tout à fait logique avec son point de vue globalement pragmatique.
        
        Tout d'abord, sa première phrase à la réponse est qu'il préfère un matériel ouvert à un matériel fermé. Ensuite il dit qu'il n'est pas pour autant contre. Et cela peut se comprendre si on adopte son point de vue sur le noyau : tout ce qui intéresse Linus c'est le code du noyau : qu'un maximum de gens l'utilisent et le hack, et qu'en fin de compte, l'obligation du GPL2 de redistribuer les modifications permettent l'incorporation de ce nouveau code dans le mainline kernel. C'est ce qu'il dit à propos d'Androïd.
        
        Ensuite, si on repense au début de l'interview où il parle des différentes licences (GPL, BSD, code fermé et autres), il dit bien qu'il n'y a pas une licence éthiquement parfaite, mais différentes licences qui selon le cas et la situation, sont appropriées.
        Donc on peut penser que Linus ne pense pas que la GPL3 soit une mauvaise licence en soit, mais qu'elle est inappropriée pour les besoins du noyau, car finalement cela restreindrait l'utilisation du kernel. Finalement, la qualité du kernel est plus ou moins directement liée au nombre de personne qui l'utilise, le teste, et le hack. C'est l'idée de l'open-source (voir La Cathédrale et le Bazar).
        
        Personnelement, je pense que c'est grâce à cette manière de penser, pragmatique et utile, qui permet que le kernel connaisse un tel essort depuis 20 ans.
        
        Cela ne signifie pas non plus que je suis pour la tivoisation ou que la FSF devrait l'être! Au contraire. Mais ce n'est pas le combat de Linus et le problème n'est de toute façon pas lié au kernel lui-même. C'est un combat plus large, plutôt social que technique.
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par Grunt le 07 mai 2011 à 14:23. Évalué à 0.
        
        cela restreindrait l'utilisation du kernel
        
        Non. Où vois-tu un passage dans la GPLv3 qui restreint l'utilisation du code?
        
        Au contraire, cela augmenterait légèrement son utilisation et le nombre de contributeurs, vu que la non-tivoïsation permettrait à une poignée de bidouilleurs de faire tourner un kernel modifié sur du matériel où ce n'est actuellement pas possible.
        
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par Littleboy le 08 mai 2011 à 01:48. Évalué à 7.
        
        Non. Où vois-tu un passage dans la GPLv3 qui restreint l'utilisation du code?
        
        C'est pas ce qu'il dit. Homme de paille grossier.
        
        Il dit qu'utiliser la GPLv3 pousserait des entreprises qui utilisent Linux a choisir un autre OS qui n'aurait pas ces contraintes (sous la forme d'un choix de leur part, pas une contrainte de la GPL).
        
        vu que la non-tivoïsation permettrait à une poignée de bidouilleurs de faire tourner un kernel modifié sur du matériel où ce n'est actuellement pas possible
        
        Parce que magiquement, des boites qui ne veulent pas qu'on puisse faire tourner du code modifie sur leur matos (majoritairement pour des raisons de licences avec les fournisseurs de contenus) vont subitement virer les restrictions si le kernel passe sous GPLv3?
        
        Vu qu'une partie de la valeur ajoutee de leur produit, c'est pouvoir diffuser du contenu et que c'est uniquement possible avec du DRM un peu solide, ils vont surtout payer une licence pour VxWorks ou autre OS embarques et laisser tomber Linux.
        
        Au final, non seulement la part de marche baisse, mais en plus les contributions au noyau par ces memes boites disparaissent du meme coup.
        
        Si t'as des exemples de boites qui ont laisse tomber la tivoisation, ca m'interesse (perso, j'ai surtout vu des boites lacher les logiciels qui passent en GPLv3 plus que le contraire).
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par Grunt le 08 mai 2011 à 15:10. Évalué à 2.
        
        Il dit qu'utiliser la GPLv3 pousserait des entreprises qui utilisent Linux a choisir un autre OS qui n'aurait pas ces contraintes (sous la forme d'un choix de leur part, pas une contrainte de la GPL).
        
        Tout comme la GPLv2 pose des contraintes qu'il n'y a pas avec une licence BSD. C'est une question de degré, pas de nature. Passer Linux sous licence BSD pourrait aussi pousser certaines boîtes à l'utiliser et à reverser une partie (mais pas tout) du code qu'elles y ajoutent.
        
        Vu qu'une partie de la valeur ajoutee de leur produit, c'est pouvoir diffuser du contenu et que c'est uniquement possible avec du DRM un peu solide
        
        Je doute un peu de la qualité de cet argument: à partir du moment où les sources sont disponibles (ce qu'impose la GPLv2), il est possible de construire un matériel pseudo-identique, d'y faire tourner le même code, et d'y ajouter un contournement de DRM. Ça nécessite du matériel, mais c'est possible (comprendre: toutes les infos sont disponibles pour le faire). Et les vendeurs de DRMerdes sont capables de comprendre ça.
        Ou alors, un détail m'échappe?
        
        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par Thomas Douillard le 08 mai 2011 à 15:20. Évalué à 4.
        
        Sans les specs, tu peux faire de la rétro ingénierie pour comprendre comment le matos fonctionne. Ca demande du temps, des compétences, mais c'est possible d'écrire un pilote. Donc ce n'est pas un problème de ne pas avoir les specs.
        
        On peut probablement refaire n'importe quoi avec du temps et des moyens et des compétences. La limite entre ce qu'il est possible et pas possible de faire est par conséquent forcément un peu arbitraire. "C'est possible" ne peut pas être "c'est possible dans l'abolu".
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par Littleboy le 08 mai 2011 à 19:55. Évalué à 8.
        
        Ou alors, un détail m'échappe?
        
        Le but etant simplement de rendre ca plus difficile pour monsieur tout le monde (ie. pas simplement cliquer sur 3 boutons et hop, disparu les protections), le type qui sort sont fer a souder, c'est vraiment plus un probleme.
        
        Et tu sous-estimes fortement la difficulte et le temps necessaire pour soit modifier le matos original, soit tout construire de zero:
        
        faire sauter des composants sans tout peter - pour remplacer les cles par exemple - ca necessite du materiel qui coute cher et pas mal de temps, sinon tu arrives a ce genre de truc
        
        faire du RE sur le logiciel, puis tout reconstruire, c'est long et complique aussi et ca ne resoud pas grand chose si la solution DRM est pas trop mauvaise (il te faut les cles, elles sont raisonnablement proteges - genre direct dans le proc donc pour les lire, il faut faire un decap'), et au final distribuer ces donnees est illegal un peu partout, meme si le reste du code qui les utilise est parfaitement distribuable.
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par GTof le 09 mai 2011 à 14:58. Évalué à -2.
        
        Justement, je ne critique pas Linus sur la technique mais justement sur son manque d'ouverture pour le reste. C'est le célèbre débat Torvalds/Stallman, open/free software. Si on pend comme principe de base que ces seules préoccupations sont la qualité du code et la propagation de Linux, sa position est totalement fondée. C'est pour cela que je disais qu'il est intélligent. Mais y a pas que la technique dans la vie, et son refus de le voir est justement ce que je trouve "con" chez lui.
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par pasBill pasGates le 10 mai 2011 à 02:08. Évalué à -1.
        
        Ben oui, tout comme les chretiens extremistes trouvent "con" le fait que plein de gens ne se convertissent pas a leur religion et donc qu'ils ne sont pas ouverts.
        
        Perso je dirais que le manque d'ouverture, il est du cote des chretiens extremistes dans ce cas.
        
        [^] # Re: Torvalds vs Stallman
        
        Posté par FantastIX le 05 mai 2011 à 14:19. Évalué à 8.
        
        On peut être à la fois con et intelligent.
        
        Le con intelligent est celui qui ne se laisse pas rentrer dedans par un gland.
- [^] # Re: Torvalds vs Stallman
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 04 mai 2011 à 09:16. Évalué à 9.
  
  « Pas de discours moralisateur […] »
  
  « l’éthique, pour moi, c’est quelque chose de privé. […] Vous devenez juste une tête de con moralisatrice. »
  
  Je me trompe ou la citation de L. Torvalds est précisément une forme de morale ; c'est-à-dire une règle de conduite, et qui plus est accompagnée d'un jugement cinglant ? Quoique ce soit dit avec un ton léger et agréable, en le posant en contre point des dérives moralisatrices usuelles ; quoique cela soit une opinion des plus séduisante ; ne serait-il pas nécessaire de garder une certaine appréciation critique vis-à-vis de notre gourou à tous et de son prophète patrick_g ? Conformément d'ailleurs à ce à quoi ils incite(raie)nt eux-même ?
  
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
  - [^] # Re: Torvalds vs Stallman
    
    Posté par Zenitram (site web personnel) le 04 mai 2011 à 09:45. Évalué à 10.
    
    Je me trompe ou la citation de L. Torvalds est précisément une forme de morale
    
    Alors comment on dit "arrêtez de me casser les coui**es avec votre morale à deux balles"?
    
    Je ne vois de morale dans la citation, juste une défense contre ceux qui veulent faire la morale.
    
    Mais bon, on retombe dans le même argument que les religieux qui estiment que les gens qui ne croient pas que dieu existe ont une croyance ;-).
    - [^] # Re: Torvalds vs Stallman
      
      Posté par Gniarf le 04 mai 2011 à 15:56. Évalué à 10.
      
      Mais bon, on retombe dans le même argument que les religieux qui estiment que les gens qui ne croient pas que dieu existe ont une croyance ;-)
      
      ça tombe bien, parce que comme par hasard ce sont des têtes de con moralisatrices
      - [^] # Re: Torvalds vs Stallman
        
        Posté par patrick_g (site web personnel) le 04 mai 2011 à 16:03. Évalué à 8.
        
        Je trouve que le "sanctimonious dick-head" de la VO est encore plus adapté.
    - [^] # Re: Torvalds vs Stallman
      
      Posté par El Titi le 04 mai 2011 à 16:13. Évalué à 5.
      
      avec votre morale à deux balles
      
      Ceci est un jugement de valeur donc moralisateur.
      Efface !!!
      
      Lâchez moi les basks avec votre morale de pacotille.
      
      Parler de morale sans terme éthique, c'est un peu comme parler du temps sans expression temporelle.
      On croirait du Saint Augustin, pour rester chez les curetons.
    - [^] # Re: Torvalds vs Stallman
      
      Posté par Étienne le 04 mai 2011 à 19:04. Évalué à 6.
      
      Mais bon, on retombe dans le même argument que les religieux qui estiment que les gens qui ne croient pas que dieu existe ont une croyance ;-).
      
      Ça dépend si tu ne crois pas que Dieu existe ou si tu crois que Dieux n'existe pas ;)
      - [^] # Re: Torvalds vs Stallman
        
        Posté par Zenitram (site web personnel) le 04 mai 2011 à 19:13. Évalué à 1.
        
        Exactement : il y en a quelqu'uns qui n'arrivent pas à faire la différence... Assez importante, surtout que quand on dit la première phrase, ils traduisent automatiquement en la deuxième et argumentent sur la deuxième, du coup totale incompréhension. J'ai mis "qui ne croient pas que dieu existe" et pas "qui croient que dieu n'existe pas" pour cette raison.
    - [^] # Re: Torvalds vs Stallman
      
      Posté par psychoslave__ (site web personnel) le 05 mai 2011 à 12:54. Évalué à 6.
      
      Mais bon, on retombe dans le même argument que les religieux qui estiment que les gens qui ne croient pas que dieu existe ont une croyance ;-).
      
      Heu, je dirait que c'est plutôt le contraire qui me dérange, à savoir les personnes qui croient en une divinité et qui qualifie tous les autres de « non-croyant ».
      
      Pour ma part, je crois en ma propre existence, et en celle d'une réalité dont je fait parti (contrairement à un point de vu idéaliste), par exemples. Je crois aussi que les assertions absurdes ne correspondent à aucune réalité.
  - [^] # Re: Torvalds vs Stallman
    
    Posté par nicolas_o le 04 mai 2011 à 09:48. Évalué à 6.
    
    "L'éthique c'est quelque chose de privé" sauf qu'en informatique, tout se fait à plusieurs.
    
    Exemples :
    - avoir le choix entre l'utilisation de deux logiciels sous deux licences différentes, toutes choses égales par ailleurs,
    - décider de libérer du code développé dans le cadre d'un travail rémunéré avec l'accord de sa hiérarchie
    
    Un choix de licence doit forcément être justifié auprès de collègues, décideurs... Donc on passe quand même pour une "tête de con moralisatrice" si on avance des arguments basés sur l'éthique.
    
    Pour linus c'est plus facile, son noyau était "juste un hobby" perso au début, donc forcément ses choix ont été strictement personnels. Mais c'est plutôt l'exception que la règle.
    - [^] # Re: Torvalds vs Stallman
      
      Posté par Anonyme le 04 mai 2011 à 12:23. Évalué à 6.
      
      La vie aussi se fait à plusieurs. :)
      Sa position a donc forcément des limites.
  - [^] # Re: Torvalds vs Stallman
    
    Posté par Sytoka Modon (site web personnel) le 04 mai 2011 à 09:50. Évalué à 3.
    
    Je me trompe ou la citation de L. Torvalds est précisément une forme de morale
    
    Il est très difficile de ne jamais porter de jugement et donc de tomber dans une forme de morale. En lisant ce même paragraphe hier soir, je me suis dis la même chose que toi. Linus dénonce quelque chose et en même temps tombe dedans ;-)
  - [^] # Re: Torvalds vs Stallman
    
    Posté par dr_home le 04 mai 2011 à 16:46. Évalué à 5.
    
    Àmha, il est préférable de se baser sur l'original pour ce genre de critiques. Littéralement, sanctimonious dick-head me semble se traduire plus par "tête de nœud sentencieuse", "moralisateur" convient donc ici dans le sens de "qui se permet de faire la morale" ; sans une certaine dose de mauvaise foi, il est alors difficile d'affirmer que Linus tombe dans ce travers...
- [^] # Re: Torvalds vs Stallman
  
  Posté par psychoslave__ (site web personnel) le 05 mai 2011 à 12:41. Évalué à 6.
  
  Mouais, moi je dirais que tout le problème de l'éthique, c'est justement de savoir ou tu places la limite flou entre le privé et le public.
  
  Avec un raisonnement comme ça, il n'est pas éthique d'interdire à de braves gens de déverser leurs ordures sur la place publique, ou de les obliger à ramasser les crottes de leur chien quand ils font sur les trottoirs des grandes villes.
  
  Là dernière fois que j'ai regardé, RMS n'obligeait personne à écouter ce qu'il raconte. Je comprends que son discours soit plus dérangeants pour les esprits qui passerait bien à la trappe toute question éthique en se targuant d'un soit disant pragmatisme. Cela étant, personne n'oblige qui que ce soit à écouter ce que raconte RMS.
  - [^] # Re: Torvalds vs Stallman
    
    Posté par pada le 14 mai 2011 à 15:55. Évalué à 3.
    
    Une phrase pleine de bon sens,
    
    Pas du tout, autant je suis admirateur de ses capacités d'informaticien et d'animateur, autant je doute de ses capacités philosophiques. Il devrait suivre un bon cours de philo, l'éthique ne peut pas se discuter sans référence aux autres.
    
    Si son approche pragmatique est intéressante, c'est justement en considérant la liberté qu'on en comprend les limites.
# Commentaire supprimé

Posté par Anonyme le 03 mai 2011 à 22:55. Évalué à -9.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Mauvais
  
  Posté par CHP le 03 mai 2011 à 23:00. Évalué à 10.
  
  Bleh, pourquoi avoir mis la traduction d'abord...et pas en commentaire ?
  
  Parce qu'on est sur un site francophone ?
- [^] # Re: Mauvais
  
  Posté par Guillaume Denry (site web personnel) le 03 mai 2011 à 23:06. Évalué à 10.
  
  L'introduction étant courte, tu n'as aucune excuse pour ne pas l'avoir lu en entier. De sucroit si tu es prêt à consacrer le temps qu'il faut pour lire le pavé de l'interview.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 03 mai 2011 à 23:38. Évalué à -10.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Mauvais
    
    Posté par bubar🦥 (Mastodon) le 03 mai 2011 à 23:55. Évalué à 10.
    
    Il y a ceux qui parlent anglais.
    Il y a ceux qui savent qu'ils ne parlent pas anglais.
    Il y a ceux qui ne savent pas qu'ils ne parlent pas anglais.
    
    Entre lire des docs techniques, des howto, des man, des sites, en anglais, et lire (réellement, avec les sous entendus, les doubles sens, les degrés, les finesses et les clins d'oeil) un texte, déjà qu'un article de journal (surtout politique) c'est dur... alors lorsqu'il s'agit d'une interview de quelqu'un comme RMS ou L.Torvalds, ben ceux qui savent lire une doc sont quant même contents que ceux sachant vraiment lire l'anglais fassent une vraie traduction...
    
    mes deux cents.
  - [^] # Re: Mauvais
    
    Posté par patrick_g (site web personnel) le 03 mai 2011 à 23:59. Évalué à 9. Dernière modification le 28 juin 2011 à 22:09.
    
    je me fous bien pas mal de l'avis du redac chef....mais alors, completement.
    
    L'intro était justement là pour indiquer aux lecteurs que la version originale allait être disponible pour ceux qui préfèrent (et qui peuvent) lire directement la prose de Linus.
    
    Ce n'est pas la traduction que je critique....c'est l'ordre dans lequel c'est mis
    
    Ben ici c'est LinuxFR donc bon....
    
    a la rigueur en faire un lien vers l'original pour que ce soit 'clair'...
    
    Un lien vers ou ? Vers ma boite mail perso ou Linus a répondu aux questions ? C'est bien plus logique de poster en commentaire.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 04 mai 2011 à 00:28. Évalué à -10.
      
      Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 04 mai 2011 à 00:35. Évalué à -9.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: Mauvais
        
        Posté par BAud (site web personnel) le 04 mai 2011 à 01:24. Évalué à 5.
        
        bien vu, j'ai rajouté un lien vers http://linuxfr.org/news/linus-torvalds%C2%A0-l%E2%80%99interview-anniversaire-des-20%C2%A0ans-du-noyau#comment-1230981 :-) (bon ouvrez dans un nouvel onglet pour ne pas flinguer les commentaires non lus et l'utilité de la toolbar).
  - [^] # Re: Mauvais
    
    Posté par gasche le 04 mai 2011 à 08:18. Évalué à 10.
    
    Une inerview, le contenu interessant sont les questions et les reponses. L'intro c'est un peu comme l'edito dans un journal:je me fous bien pas mal de l'avis du redac chef....mais alors, completement.
    
    Tu pourrais être un peu plus respectueux. Ici le "rédac chef" c'est le gars qui s'est décarcassé pour trouver des questions intéressantes à poser, qui a fait l'effort de traduire... Je trouve que c'est assez gonflé de dire "je m'en fous de son avis" et de râler parce qu'en réalité l'introduction contenait une information importante.
    
    Ta remarque sur l'ordre traduction/original est légitime. Mais je pense que les gens t'écouteraient plus si tu formulais ta remarque de façon moins insultante.
  - [^] # Re: Mauvais
    
    Posté par gilles renault (site web personnel, Mastodon) le 04 mai 2011 à 08:44. Évalué à 8.
    
    sur l'informatique....franchement un informaticie/feru d'informatique n qui parle pas anglais,ca me fait marrer...
    
    Si tu voyais le nombre d'étudiants en DUT info qui ont peur de l'anglais...
  - [^] # Re: Mauvais
    
    Posté par Jiel (site web personnel) le 04 mai 2011 à 14:14. Évalué à 10.
    
    Et sur l'informatique....franchement un informaticie/feru d'informatique n qui parle pas anglais,ca me fait marrer...
    
    Oui, aujourd'hui, quand on fait de l'informatique, on est obligé de parler anglais, c'est un fait ! Mais on est pas obligé d'encourager cette pratique, qui renforce encore l'hégémonie anglo-saxonne. C'est bien de traduire à chaque fois qu'on le peut.
    
    D'autre part, il ne faut pas oublier que tous les linuxiens ne sont pas des informaticiens ni nécessairement des férus d'informatique. Et ils ne sont pas forcément contre l'anglais : peut-être qu'ils ne parlent pas anglais, pour tout un tas de raisons, peut-être aussi qu'ils parlent un tas d'autres langues.
    
    Si on considère qu'une grande et longue interview ne doit pas être traduite, car tout le monde parle anglais, dans ce cas, ce n'est plus la peine d'écrire et de parler français, autant parler à l'anglais tout de suite !
    - [^] # Re: Mauvais
      
      Posté par Albert_ le 04 mai 2011 à 15:26. Évalué à -6.
      
      C'est amusant comme tu as un probleme avec les langues etrangeres. Tu peux te battre contre le fait que l'anglais est, actuellement, la langue utilise dans les echanges. Cela ne changera pas grand chose. Si tu voulais que cela soit le francais tu es ne 2 ou 3 siecles trop tard, pour l'allemand c'etait fin 19eme, debut 20eme et dans quelques temps cela devrait etre le chinois. C'est juste une question de localisation du barycentre des decouvertes scientifiques et de l'influence economico-politique. Et je vois tres tres mal la tendance allant de nouveau vers le francais...
      
      Dans le meme ordre d'idee avoir des difficultes pour apprendre une langue etrangere ce n'est pas une fatalite.
      
      Je dois aussi rajouter que le fait de refuser de se voir ce qui se passe a cote fait que lorsque malgre tout cela arrive dans ton petit monde c'est juste totalement obselete. C'est un peu une maladie francaise, etre a la course derriere les autres. Un bon exemple etant les liseuses/ereader, la France est un des pays les plus en retard sur le sujet avec des arguments tellement passeiste que cela en est risible si cela ne mettait pas en danger le futur de ce pays. Reveillez vous un petit peu le pays de vos grands-parents n'existent plus et meme si cette generation la fait en sorte de mettre la France en etat de stase ce n'est pas une bonne idee!
      - [^] # Re: Mauvais
        
        Posté par Jiel (site web personnel) le 04 mai 2011 à 16:26. Évalué à 10.
        
        C'est amusant comme tu as un probleme avec les langues etrangeres.
        
        Je n'ai aucun problème avec les langues étrangères. J'en parle/lis/écris plusieurs, plutôt bien, dont l'anglais.
        
        Tu peux te battre contre le fait que l'anglais est, actuellement, la langue utilise dans les echanges.
        
        Je ne me bats pas contre l'anglais langue internationale. C'est un fait. Mais c'est une attitude et un processus que je ne veux pas encourager. D'autre part, je nuancerai ton propos : il y a encore des tas de zones ou l'anglais n'est pas la langue des échanges, par exemple le français en Afrique, l'arabe au Moyen-Orient ou le russe en ex-URSS.
        
        Mais ce que peut-être tu ne mesures pas, c'est que le choix d'une langue n'est pas sans conséquences.
        
        Le tout anglais avantage notablement les pays anglophones. Même si tu deviens très bon en anglais, voire bilingue, tu ne maîtriseras jamais l'anglais comme ceux qui l'ont comme langue maternelle. Donc, en situation de conflit, de négociation etc., tu seras désavantagé. Sans compter qu'à travers la langue passe aussi une certaine perception du monde.
        
        Au final, le choix du tout anglais désavantage (culturellement, économiquement, ...) les locuteurs anglophones "seconde langue". Donc en particulier les francophones. Enfin, malgré l'école et tout un tas de choses, des gens qui parlent vraiment bien anglais, il y en a pas tant que ça (pour tout un tas de raisons, pas de pratique régulière, pas pu faire de séjour dans un pays anglophone etc.). Et ton attitude à considérer que tout le monde parle anglais consiste à les exclure.
        
        Je pense donc que le plurilinguisme est une solution plus intéressante. Et surtout, quand on est entre francophones (ou des gens qui parlent tous une autre langue), le mieux est de ne pas employer l'anglais. Si les francophones ne défendent pas leur langue, personne ne le fera à leur place, et surtout pas les anglophones.
        
        Je dois aussi rajouter que le fait de refuser de se voir ce qui se passe a cote fait que lorsque malgre tout cela arrive dans ton petit monde c'est juste totalement obselete.
        
        Parler français entre francophones plutôt qu'anglais ce n'est pas obsolète.
        
        C'est un peu une maladie française, etre a la course derriere les autres.
        
        Une réforme, un changement, ce n'est pas forcément une avancée. C'est même parfois l'inverse. La preuve avec les nombreuses réformes proposées par le gouvernement français actuel. Imiter les autres, ce n'est pas forcément une bonne solution.
      - [^] # Re: Mauvais
        
        Posté par sifu le 04 mai 2011 à 16:42. Évalué à 10.
        
        Je ne vois pas en quoi quelqu'un qui préfère lire un truc en français à un problème avec les langues étrangères. Je trouve cela un peu réducteur.
        
        On est sur un site d'actualités francophone. On vient pas forcément ici parce qu’on est des gaulois puant d'orgueil ...
      - [^] # Re: Mauvais
        
        Posté par CHP le 04 mai 2011 à 18:20. Évalué à -1.
        
        C'est un peu une maladie francaise, etre a la course derriere les autres. Un bon exemple etant les liseuses/ereader, la France est un des pays les plus en retard sur le sujet avec des arguments tellement passeiste que cela en est risible si cela ne mettait pas en danger le futur de ce pays.
        
        Si je comprends bien, tu viens de dire que le fait de ne pas pouvoir télécharger le dernier prix goncourt sur ereader met en danger le futur de la France ? MOUARF !
        
        [^] # Re: Mauvais
        
        Posté par Albert_ le 04 mai 2011 à 18:53. Évalué à 1.
        
        Presente comme cela c'est en effet debile mais presente comme:
        
        "Un milliard de ebook vendu en deux ans par Amazon" cela l'est un tout petit peu moins.
        
        [^] # Re: Mauvais
        
        Posté par CHP le 05 mai 2011 à 10:39. Évalué à 0.
        
        Meme avec cette info, ca me parait très largement exagéré. Cela met en danger les maisons d'edition francaises, mais c'est tout : cela n'impacte ni les auteurs (ils peuvent toujours se faire éditer ailleurs), ni le reste de la société francaise. Enfin si, si les maisons d'edition faisaient des ebooks, elles pourraient vendre un peu plus, et l'etat gagnerait donc un peu plus, mais bon, c'est minime !
        
        [^] # Re: Mauvais
        
        Posté par Albert_ le 05 mai 2011 à 14:18. Évalué à 4.
        
        Sais tu que l'arrive des voitures ont mis la plupart des eleveurs de chevaux en danger? De meme les machines a laver le linge ont mis toutes ces pauvres dames qui aller battre le linge au lavoir au chomage. Une honte mon bon monsieur.
        
        De plus je vois que tu fais une erreur, classique, melangeant allegrement editeur et immprimeur. Le travail d'editeur n'est absolument pas touche par la revolution que nous sommes en train de vivre. Celui des imprimeurs c'est autre chose.
        
        Vu ta reaction, mon exemple sur le fait que certains francais font tout pour que le pays reste a l'epoque des annees 90 est bien une realite.
        
        [^] # Re: Mauvais
        
        Posté par CHP le 05 mai 2011 à 22:49. Évalué à 3.
        
        Bon, manifestement tu as très mal pris mon commentaire. Je te présente mes excuses, je ne souhaitais pas du tout t'agresser, simplement te faire remarquer que tu exagérais largement.
        
        Sais tu que l'arrive des voitures ont mis la plupart des eleveurs de chevaux en danger? De meme les machines a laver le linge ont mis toutes ces pauvres dames qui aller battre le linge au lavoir au chomage. Une honte mon bon monsieur.
        
        Oui, je sais que la voiture a mis pas mal de marechaux ferrants et d'eleveur de chevaux au chomage (au passage, bravo, t'as réussi à me prendre pour plus con que je ne le suis - c'est une performance, parce que j'ai déja un sacré niveau). Après, je vois pas le rapport avec la discussion : le milieu de la vente de bouquin en france ne s'est pas adapté aux ebooks, alors que c'est probablement une grosse menace pour eux, et alors ? En quoi est ce que ca met l'avenir de la France entière en danger ? J'aimerais que tu m'explique en quoi, parce que ca me concerne, si mon avenir est en danger (oui, je suis francais).
        
        De plus je vois que tu fais une erreur, classique, melangeant allegrement editeur et immprimeur. Le travail d'editeur n'est absolument pas touche par la revolution que nous sommes en train de vivre. Celui des imprimeurs c'est autre chose.
        
        Tu as probablement raison. Je connais très mal ce milieu et les différents métiers qui le compose. Au temps pour moi, c'est certainement une erreur de ma part
        
        Vu ta reaction, mon exemple sur le fait que certains francais font tout pour que le pays reste a l'epoque des annees 90 est bien une realite.
        
        Merci, c'est la deuxième fois dans la meme discussion que tu me fais pouffer de rire !
        
        J'ai simplement fait remarquer que le fait de dire que le retard des francais sur les e-book allait mettre le pays entier en danger était très certainement une enorme éxagération, et maintenant c'est de ma faute s'ils sont en retard, je fais partis des "francais (qui) font tout pour que le pays reste à l'epoque des annes 90".
        
        Tu sais, c'est pas grave que tu aies dit une éxagération tellement enorme qu'elle pourrait passer pour une belle connerie. Ca arrive à tout le monde, faut pas s'enerver pour ca ! De là a accuser la personne qui te le fait remarquer d'être responsable du retard de toute une corporation dont il ne fait pas partie et dont il se fout completement... J'ai du mal a voir le rapport !
        
        Au fait, tu sais que je suis également responsable de la faim dans le monde, de l'epidemie de sida en afrique et de la disparition des abeilles ?
        
        [^] # Re: Mauvais
        
        Posté par PachaFonk le 06 mai 2011 à 09:04. Évalué à 9.
        
        Au fait, tu sais que je suis également responsable de la faim dans le monde, de l'epidemie de sida en afrique et de la disparition des abeilles ?
        
        Et ben putain, tu as intérêt à mieux te cacher que Ben Laden !
        
        [^] # Re: Mauvais
        
        Posté par zebra3 le 29 mai 2011 à 09:46. Évalué à 2.
        
        Et à t'accrocher pour faire tomber le record :
        http://pete.com/files/photos/hide-and-seek-champion.jpg
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
    - [^] # Re: Mauvais
      
      Posté par Anonyme le 05 mai 2011 à 10:36. Évalué à 1.
      
      Oui, aujourd'hui, quand on fait de l'informatique, on est obligé de parler anglais, c'est un fait ! Mais on est pas obligé d'encourager cette pratique, qui renforce encore l'hégémonie anglo-saxonne. C'est bien de traduire à chaque fois qu'on le peut.
      
      Tiens, il serait intéressant de ressortir la dépêche sur Firefox en brezhoneg. :)
      - [^] # Re: Mauvais
        
        Posté par BAud (site web personnel) le 08 mai 2011 à 16:05. Évalué à 2.
        
        et hop un ch'ti tag http://linuxfr.org/tags/brezhoneg/public
  - [^] # Re: Mauvais
    
    Posté par Mat (site web personnel) le 14 mai 2011 à 12:39. Évalué à 5.
    
    Encore un chevalier blanc, défendeur de l'anglicisation. Ces pauvres anglophones ont vraiment besoin qu'on prennent leur défense.
    Quel noble combat!
    Franchement, les francophones victimes du syndrome du larbin (je cherche à ressembler aux maîtres) qui viennent réclamer plus d'anglais sur des sites francophones, mais qu'est ce que vous foutez sur linuxFr ?
    Mais vraiment, à quoi sert ce genre de commentaires si ce n'est vraiment, se larbiniser, "hé regardez!! j'en suis! je lis la langue de mes maîtres!".
    Ils servent à rien ces commentaires, alors arrêtez de venir sur linuxFR et allez vous "satisfaire" sur les sites anglophones.
    Par avance, merci!
- [^] # Re: Mauvais
  
  Posté par bluelambda le 04 mai 2011 à 16:30. Évalué à 10.
  
  Boulet.
  On s'en fout de l'ordre d'apparition. Lis la version qui te convient. Et respecte le travail du traducteur même si tu préfères lire la VO.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 05 mai 2011 à 23:37. Évalué à -1.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# Micro-noyaux

Posté par bobert le 03 mai 2011 à 23:22. Évalué à 10.

Moi, ce que j'ai préféré, c'est ses réflexions sur les micro-noyaux. Je trouve que c'est à méditer, parce que c'est issu d'une expérience conséquente d'un système complexe (le noyau linux), et ça rejoint ce que nous disent les disciplines qui se frottent à d'autres systèmes complexes (neurosciences fonctionnelles, ingénierie des systèmes, ...).

Merci pour l'interview et le boulot que ça a représenté.
# Hi, LWN ! :)

Posté par gnuzer (site web personnel) le 03 mai 2011 à 23:24. Évalué à 10.

http://lwn.net/Articles/441207/
- [^] # Re: Hi, Hacker News ! :)
  
  Posté par Nic0 (site web personnel) le 04 mai 2011 à 20:28. Évalué à 4.
  
  Pas mal de commentaires sur Hacker News également:
  
  http://news.ycombinator.com/item?id=2513123
# Interview de 1998

Posté par Pierre Jarillon (site web personnel) le 03 mai 2011 à 23:29. Évalué à 10.

En 1998, Sébastien Blondeel avait traduit à ma demande une interview de Linus. Seule cette traduction en français est actuellement disponible, la version originale en anglais semble avoir disparu.
Il est intéressant de comparer ces deux interview, aussi bien pour la qualité des questions que pour les réponses de Linus.

Le manifeste de Linux (1998) par D. Vincent (BootNet), adapté par S. Blondeel.
- [^] # Re: Interview de 1998
  
  Posté par monseigneur le 04 mai 2011 à 00:35. Évalué à 4.
  
  Merci pour ce lien. C'est intéressant de comparer les deux entretiens et voir le chemin parcouru par Linux.
- [^] # Re: Interview de 1998
  
  Posté par Low Memory le 05 mai 2011 à 02:17. Évalué à 6.
  
  La version originale de l'interview de l'époque est disponible en ligne sur un site brésilien !
  
  Ça me fait penser à un article: La mémoire vide des temps informatisés, sur le problème -bien connu ici, je suppose- des sauvegardes à long terme. Quelles archives laisseront nous derrière nous ?
- [^] # Re: Interview de 1998
  
  Posté par Anonyme le 05 mai 2011 à 13:38. Évalué à 4.
  
  Tiens un petit cadeau (l'interview en question en VO).
  - [^] # Re: Interview de 1998
    
    Posté par Anonyme le 05 mai 2011 à 13:45. Évalué à 4.
    
    Bleh
    
    Voilà ce que c'est d'avoir un système d'exploitation fiable dans lequel tu peux avoir confiance. Tu ouvres tout plein de choses, puis tu vas dormir sans rien fermer ni éteindre. Puis tu te réveilles, vaques à tes occupations, et quand tu reviens tout est encore là et t'a attendu bien sagement. Mais comme un con tu oublies que c'est toi, l'interface chaise-clavier, le maillon faible. Et tu réponds à un commentaire sans mettre à jour la page avant...
  - [^] # Re: Interview de 1998
    
    Posté par Pierre Jarillon (site web personnel) le 05 mai 2011 à 22:22. Évalué à 4. Dernière modification le 07 septembre 2014 à 15:02.
    
    Merci pour le lien et merci au brésilien qui a conservé le texte original.
    
    Il faut aussi noter que "fairy pinguin" est un manchot pygmée (Eudyptula minor). Avec Sébastien Blondeel, nous n'avions pas trouvé la traduction. Internet n'était pas ce qu'il est aujourd'hui !
# merci

Posté par siger le 04 mai 2011 à 00:44. Évalué à 4.

Merci pour cette interview de Linus. Ses interviews sont moins courantes que celles de Stallman et il a une vision plus pragmatique qui contraste avec celle de Monsieur Stallman (qui est valable néanmoins) et est intéressante. Il contribue aussi plus que Monsieur Stallman et on a le témoignage d'un acteur important de Linux. Il permet aussi de témoigner de l'évolution de Linux et j'adore l'idée de ne se concentrer que sur Linux et les logiciels libres plus que sur les concurrents et la comparaison avec les concurrents.
- [^] # Re: merci
  
  Posté par Sytoka Modon (site web personnel) le 04 mai 2011 à 09:54. Évalué à 6.
  
  Il contribue aussi plus que Monsieur Stallman
  
  Les deux personnes sont aujourd'hui des chefs de projet. Tu connais beaucoup de chef de projet de cette importance qui code encore avec leurs dix doigts ?
  
  Par ailleurs, ils n'ont pas le même âge.
  
  Bref, je me garderais bien de faire le moindre jugement aussi rapide et j'ai une grande estime des deux personnes pour tout ce qu'elles ont fait et pour tout ce qu'elles font encore aujourd'hui.
  - [^] # Re: merci
    
    Posté par claudex le 04 mai 2011 à 10:06. Évalué à 9.
    
    Linus code encore beaucoup, sans compter Git récemment, il résoud encore des bugs dans le noyau.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
    - [^] # Re: merci
      
      Posté par j_kerviel le 04 mai 2011 à 13:01. Évalué à 2.
      
      Linus code encore beaucoup, sans compter Git récemment, il résoud encore des bugs dans le noyau.
      
      Vraiment ?
      
      Il me semblait qu'il ne codait justement plus beaucoup.
      
      Pour ce qui est du kernel, il me semble qu'il avait déclaré qu'il passait la majeure partie de son temps à refuser des patches et argumenter (plus ou moins calmement). Et également pas mal de temps à faire des merges et communiquer.
      
      Pour ce qui est de git, il n'est même pas listé dans les contributeurs (est ce que ça veut dire qu'il n'a pas commité depuis que git a été jugé suffisamment stable pour se hoster lui même ?)
      https://github.com/git/git/contributors
      - [^] # Re: merci
        
        Posté par cosmocat le 04 mai 2011 à 16:05. Évalué à 8.
        
        Pour ce qui est de git, il n'est même pas listé dans les contributeurs (est ce que ça veut dire qu'il n'a pas commité depuis que git a été jugé suffisamment stable pour se hoster lui même ?)
        
        Git a réussi à s'autohéberger au bout de 5 jours de développement (pour info, contre 1 an pour svn). Donc je te rassure, Linus a travaillé plus longtemps sur Git que çà. C'est un génie mais bon quand même :D
        
        Par contre, je sais plus quand c'est qu'il a passé la main en tant que mainteneur du projet.
        
        Pour alimenter le débat, je crois qu'il code encore un peu mais pas assez à son goût...
        
        [^] # Re: merci
        
        Posté par cosmocat le 04 mai 2011 à 17:20. Évalué à 6.
        
        Bon, j'ai la réponse :)
        Il a passé la main en tant que mainteneur du projet au bout de 3 mois (un peu après que Git ait été capable d'héberger le noyau linux).
        
        [^] # Re: merci
        
        Posté par j_kerviel le 05 mai 2011 à 13:29. Évalué à 5.
        
        Pour ce qui est de git, il n'est même pas listé dans les contributeurs (est ce que ça veut dire qu'il n'a pas commité depuis que git a été jugé suffisamment stable pour se hoster lui même ?)
        
        Git a réussi à s'autohéberger au bout de 5 jours de développement (pour info, contre 1 an pour svn). Donc je te rassure, Linus a travaillé plus longtemps sur Git que çà. C'est un génie mais bon quand même :D
        
        Ok merci pour la réponse.
        
        Mais alors pourquoi son nom n'apparait pas ?
        
        Ça veut dire que son nom a sauté lors d'une migration ?
        
        Moi qui croyait que git était solide, à toute épreuve etc.
        
        [N.B.: Pas d'ironie ici. Juste de la surprise. Je suis un adepte de git, ça a changé ma vie. j'adore l'outil et je ne changerais pour rien au monde]
        
        [^] # Re: merci
        
        Posté par chtitux (site web personnel) le 06 mai 2011 à 12:55. Évalué à 3.
        
        Il doit faire probablement une grande partie des merges (cf https://github.com/mirrors/linux-2.6/commits/master ) et il ne doit pas être crédité de l'auteur du commit (ce qui est normal, git sépare bien auteur et commiter).
        
        Ça suppose qu'il lit une grande partie des patches, qu'il les commente, qu'il dit ce qui ne va pas et demande probablement à l'auteur original de corriger. Donc à la fin, même s'il a repéré et aurait pu corriger le patch, il n'est pas l'auteur de celui-ci, donc en SLOC, il représente peu.
        
        [^] # Re: merci
        
        Posté par cosmocat le 06 mai 2011 à 14:10. Évalué à 2.
        
        je n'ai pas compris exactement le sens de ta question mais...
        
        je ne pense pas qu'il écrive encore du code pour git
        
        je ne pense pas non plus qu'il écrive du code pour linux pour ajouter des nouvelles fonctionnalités. Par contre, il corrige encore quelques (petits) bugs (des messages de commit à son nom sont visibles dans le changelog des RCs). Je pense aussi qu'il doit écrire des bouts de code pour tester certaines solutions techniques et ensuite envoyer l'idée (et le code) à certains mainteneurs et développeurs.
        
        Son travail est essentiellement du merge et test à l'heure actuelle.
      - [^] # Re: merci
        
        Posté par Matthieu Moy (site web personnel) le 07 mai 2011 à 13:34. Évalué à 10.
        
        https://github.com/git/git/contributors
        
        Euh, ça, c'est un miroir (non-officiel) sur Github. Si j'ai bien compris, ça ne liste que les gens qui ont un compte sur github.
        
        Pour une liste plus précise, cf. http://git-scm.com/about où tu peux voir que Linus est bon troisième contributeur.
        
        Pour plus de détails :
        
        $ git log --date=short --format='%ad' --author=Linus Torvalds | cut -d - -f 1 | sort -k 2 | uniq -c
        680 2005
        162 2006
        110 2007
        81 2008
        48 2009
        16 2010
        3 2011
        
        On voit qu'il contribue effectivement beaucoup moins ces dernières années. Comme il le dit très bien dans l'interview, il a été un excellent architecte pour Git (bon, il n'a pas tout inventé non plus, il connaissait très bien bitkeeper de l'extérieur, et a repris beaucoup d'idées de Monotone). Mais quand l'effort sur Git a commencé à arriver sur l'interface utilisateur, la portabilité & co, il a vraiment passé la main parce que ce n'est pas là qu'il est bon (et qu'il a un autre projet qui l'occupe un peu). Les patchs qu'il a écrit ces derniers temps sont en général des trucs écrits parce qu'il en avait besoin pour le kernel.
        
        [^] # Re: merci
        
        Posté par Antoine le 08 mai 2011 à 14:44. Évalué à 3.
        
        et qu'il a un autre projet qui l'occupe un peu
        
        Il a commencé à écrire un moteur de blog ? :-o
        
        [^] # Re: merci
        
        Posté par zebra3 le 29 mai 2011 à 09:49. Évalué à 2.
        
        Non, juste un blog : http://torvalds-family.blogspot.com/ ;-)
        
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: merci
    
    Posté par Antoine le 05 mai 2011 à 16:18. Évalué à 9.
    
    Il contribue aussi plus que Monsieur Stallman
    
    Les deux personnes sont aujourd'hui des chefs de projet. Tu connais beaucoup de chef de projet de cette importance qui code encore avec leurs dix doigts ?
    
    Le logiciel libre, ce n'est pas le monde merveilleux de l'entreprise, où la distinction donneur d'ordres / exécutant sert à mettre en conformité le mode de production avec une certaine idée de l'ordre social (hiérarchique avec stricte séparation des torchons et des serviettes).
    
    Par ailleurs, contribuer n'implique pas de coder soi-même : faire des revues de code, etc., c'est aussi contribuer. Je pense que Torvalds est toujours aussi actif de ce côté-là.
    
    Je pense que ce que veut dire le commentaire original, c'est que RMS a troqué son activité de contributeur contre une activité de militant, et c'est ce qui le rend moins légitime pour parler aujourd'hui, concrètement, de logiciel libre (d'ailleurs, il n'en parle plus vraiment concrètement, se spécialisant plutôt dans un discours général de type moralisateur).
# Concernant le pragmatisme

Posté par J Avd le 04 mai 2011 à 01:48. Évalué à 10.

D'abord bravo pour les questions, l'interview est super à lire (en VF et en VO), super boulot du traducteur, un grand merci à Linus Torvald. Messieurs chapeau bas!

Je lis les remarques sur le fait que LT c'est mieux que RMS parce-que-c'est-plus-pragmatique-et-moins-moralisateur blabla ...

Certes, néanmoins je pense que c'est justement le fait d'avoir ces deux visions qui porte. On a vraiment deux positions diamétralement opposés, et chacun de nous se reconnais un peu dans les deux a des degrés différents et c'est ça qui fait qu'on adhère au projet global.

Ces deux discours sont peu répandus dans la population, mais il constitue une balance intéressante et à mon avis assez novatrice (oserais je dire une philosophie ?).

Dommage que la portée soit si faible et se borne aux geeks et aux nerdz.

"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
- [^] # Re: Concernant le pragmatisme
  
  Posté par Médéric RIBREUX (site web personnel) le 04 mai 2011 à 09:31. Évalué à 10.
  
  Hello,
  
  Certes, néanmoins je pense que c'est justement le fait d'avoir ces deux visions qui porte.
  
  je suis assez d'accord avec cette affirmation. En fait, le logiciel libre ce n'est pas Torvalds vs Stallman (pour reprendre un titre un peu plus haut), c'est bien Torvalds ET Stallman.
  
  On a d'un côté le technicien organisateur qui ne jure que par la technique (pragmatique), de l'autre, le défenseur des valeurs, le père fondateur, le politique. Les deux individus, se complètent très bien: chacun se concentre sur ce qu'il sait faire. Le code source relie les deux.
  
  Je ne pense pas que Linus Torvalds ait pu avoir autant de succès ni de réussite technique s'il était parti de rien: c'est à dire, sans les outils GNU mais également sans un exemple concret de développeurs qui essayent de construire un système d'exploitation en collaboration, à partir de rien.
  
  Pour aller plus loin, Linus Torvalds indique qu'il a déjà travaillé sur des licences commerciales et que ça ne l'a pas gêné. On peut donc imaginer que s'il avait trouvé des conditions adéquates à son intérêt personnel dans un développement "ouvert" (comme dans open source) mais propriétaire d'un noyau, Linux serait peut-être aujourd'hui un noyau certes techniquement bon (en regard des capacités de l'auteur du code) mais fermé et utilisé, au hasard, par une grosse boîte de téléphonie mobile. Je pense que, dans ces conditions, c'est le noyau HURD qui aurait rallié l'intérêt global et qu'on ne parlerait plus que du système d'exploitation GNU (ou qu'on en parlerait peut-être pas du tout).
  
  A l'inverse, c'est sans doute par ce côté pragmatique et décomplexé des valeurs que le développement du noyau Linux connaît autant de succès avec, notamment, la reconnaissance par le monde commercial qui aurait sans doute été moins facile à obtenir avec l'approche très éthique du projet GNU.
  
  Pour terminer, même s'ils ne s'apprécient sans doute pas trop l'un l'autre, nous avons tous besoin du travail de RMS et de LT...
  - [^] # Re: Concernant le pragmatisme
    
    Posté par CHP le 04 mai 2011 à 13:56. Évalué à 8.
    
    En fait, le logiciel libre ce n'est pas Torvalds vs Stallman (pour reprendre un titre un peu plus haut), c'est bien Torvalds ET Stallman.
    
    Je suis completement d'accord (et pourtant c'est moi qui ai ecrit le commentaire dont tu cite le titre).
    
    Je ne comparais pas les personnes, ni leurs contributions au logiciel libre, mais simplement le plaisir que j'ai à lire leurs interviews. Et de ce coté là, Linus est largement au dessus.
    
    Je trouve que les interviews de RMS sont un peu toujours les memes, avec toujours ce coté moralisateur, toujours le coté "c'est comme ceci et si vous n'etes pas d'accord c'est que vous ne comprenez rien", etc. A la longue, je le trouve fatigant, et lire une interview de Linus me parait comme un bol d'air frais.
    
    Mais ceci n'est que mon avis. Et il ne faut pas oublier que je ne suis qu'un (gros ?) con !
  - [^] # Re: Concernant le pragmatisme
    
    Posté par fredix le 04 mai 2011 à 14:50. Évalué à 9.
    
    Je pense que, dans ces conditions, c'est le noyau HURD qui aurait rallié l'intérêt global et qu'on ne parlerait plus que du système d'exploitation GNU (ou qu'on en parlerait peut-être pas du tout).
    
    Tu vas un peu vite en besogne. C'est Linus qui a inventé le développement dit du bazar, alors que la FSF et toute l'industrie du logiciel d'ailleurs, utilisaient le développement pyramidale (lire la cathédrale et le bazar de Eric Raymond : http://www.linuxfr-france.org.invalid/article/these/cathedrale-bazar/cathedrale-bazar_monoblock.html ).
    
    Or sa méthode, qui est le standard actuel dans le libre, a vraiment permis d'attirer de nombreux développeurs et d'avancer très vite. En l'occurrence il peut être permis de douter que Hurd aurait pris le même chemin en l'absence de Linux. Linus avec ses compétences, sa persévérance, ses méthodes et son charisme ont pu donner Linux tel que nous le connaissons 20 ans plus tard.
- [^] # Re: Concernant le pragmatisme
  
  Posté par CrEv (site web personnel) le 04 mai 2011 à 14:23. Évalué à 3.
  
  Je lis les remarques sur le fait que LT c'est mieux que RMS parce-que-c'est-plus-pragmatique-et-moins-moralisateur blabla ...
  Certes, néanmoins je pense que c'est justement le fait d'avoir ces deux visions qui porte
  
  Ben d'ailleurs c'est un peu ce que Torvalds répond dans l'interview, par exemple sur les brevets :
  
  Je suis bon dans ce que je fais et je pense qu’il y a des gens qui sont meilleurs que moi pour combattre ce bordel des brevets.
  
  Ca a un petit côté "chacun à sa place" et, je trouve, cadre plutôt bien avec le côté pragmatique de Torvalds.
  
  Maintenant, je pense qu'il y a tout de même une divergence, qui est juste dans la suite :
  
  Et je pense que ça doit être combattu depuis l’intérieur du système — donc je m’attends à ce que la solution vienne en réalité des entreprises qui seront impactées par tout ce bazar.
  
  RMS aurait plutôt tendance à mettre tout ça sur l'utilisateur, dire à l'utilisateur que c'est à lui de ne pas s'enfermer dans le proprio, etc, Torvalds plutôt que c'est aux entreprises (dans le cadre des brevets, donc par similarité aux développeurs pour les logiciels) de comprendre, de réaliser qu'ils font fausse route. C'est finalement un peu la différence entre logiciel libre (libre car c'est l'objectif) et open source (libre car c'est juste plus mieux)
# et en relief : Gates et Jobs

Posté par TuxMips le 04 mai 2011 à 07:55. Évalué à 6.

Bonjour,

Merci beaucoup pour ce très bel interview.

Hier j'ai lu cet article sur Agoravox

Sincèrement je trouve que Linus et son noyau se trouve complètement au dessus de la mêlée.

Et c'est cela qui me plait :-)

C'est aussi cela qui fonde mon choix pour mon informatique personnelle
# a propos de android

Posté par Albert_ le 04 mai 2011 à 09:12. Évalué à 2.

Mode ironique: Puti il y connais rien ce gars.

Android is an example of lots of mainstream users for

J'espere que cela arretera les idioties de certains sur le sujet.
# Que du bien !

Posté par napster2core le 04 mai 2011 à 11:38. Évalué à 5.

Et hop, 30 minutes de glande (enfin, lecture assidue...) aux frais de mon patron.
Excellent interview, les questions ne sont pas les questions bêtes et habituelles.
Un grand merci à l'équipe de rédaction et, bien évidement, à Linus !

Si tu ne sais pas demande, si tu sais partage !
- [^] # Re: Que du bien !
  
  Posté par Zenitram (site web personnel) le 04 mai 2011 à 11:46. Évalué à 10.
  
  Et hop, 30 minutes de glande (enfin, lecture assidue...) aux frais de mon patron.
  
  Met ça dans la ligne "veille technologique".
- [^] # Re: Que du bien !
  
  Posté par jean le 04 mai 2011 à 15:35. Évalué à 2.
  
  Excellent interview, les questions ne sont pas les questions bêtes et habituelles.
  
  Je trouve aussi que le choix des questions est intéressant et bien équillibré partagé entre l'actualité de court terme et celle de long terme, quelques questions un peu politiques d'autres plus techniques.
  
  Les réponses de Torvalds sont toutes assez nuancées et argumentées ... dommage qu'il ne poste pas ici plus souvent :)
# Bonne interview

Posté par bilboa le 04 mai 2011 à 11:39. Évalué à 3.

J'aurais posé les questions moi même j'aurais posé les mêmes.
Ben dit donc, ca m'arrive pas souvent de dire ca. Ca fait assez plaisir comme interview.

Je suis plutôt d'accord avec Linus sur le coté cirque de la sécurité, qui est plutôt nauseabon (voir les tweet de vupen en France par exemple)

Par contre je pense qu'il sous-estime le problème général, et l'intérêt de Singularity (et autres). En effet les systèmes actuels sont bien trop faibles niveau sécurité et on ne peut pavoir aucune vrai confiance dans son PC. Ca n'est pas normal ni perein. Singularity (et autres) changent la donne.
- [^] # Re: Bonne interview
  
  Posté par Martin Peres (site web personnel) le 04 mai 2011 à 12:07. Évalué à 5.
  
  Avant de parler de la sécurité de Singularity, j'attend de voir un OS qui marche. Avec 35 devs, on est pas prêt de le voir arriver cet OS.
  
  Perso, je dirai qu'avant de parler de la sécu du kernel, faudrait mieux contrôler ce que font les applications en userspace (contrôle des appels systèmes et des accès mémoire). Je peux t'assurer que si tu fais ça bien, tu auras déjà une sécu bien béton!
  
  Des solutions existent pour faire ça, mais elles ne sont pas connues. J'espère que ça va changer.
  - [^] # Re: Bonne interview
    
    Posté par Albert_ le 04 mai 2011 à 12:53. Évalué à 9.
    
    Tant que tu contreleras pas l'interface chaise-clavier les problemes de securite tu en auras toujours.
    - [^] # Re: Bonne interview
      
      Posté par Martin Peres (site web personnel) le 06 mai 2011 à 15:26. Évalué à 1.
      
      C'est une évidence ;) Mais rendre plus visible les attaques, c'est important.
      
      C'est ce qu'essaye de faire microsoft avec son UAC mais y'a trop de programmes qui requièrent les droits administrateurs pour s'installer que finalement, ça perd son intérêt.
  - [^] # Re: Bonne interview
    
    Posté par reno le 04 mai 2011 à 13:49. Évalué à 4.
    
    Avant de parler de la sécurité de Singularity, j'attend de voir un OS qui marche. Avec 35 devs, on est pas prêt de le voir arriver cet OS.
    
    D'où tu sors les 35 devs? Je pensais que Singularity était juste un projet de recherche des laboratoires Microsoft?
    Pour autant que je sache il n'est pas développé du tout: as-tu plus d'infos ou confonds-tu avec autre chose?
    
    Perso, je dirai qu'avant de parler de la sécu du kernel, faudrait mieux contrôler ce que font les applications en userspace (contrôle des appels systèmes et des accès mémoire). Je peux t'assurer que si tu fais ça bien, tu auras déjà une sécu bien béton!
    
    Sauf que Linux n'est pas non plus bien situer de ce coté: les développeurs de Chrome, une des rare application a faire justement ce contrôle des appels systèmes, se plaignaient que Linux n'offraient pas de moyen "standard" d'implémenter leur 'bac à sable'..
    - [^] # Re: Bonne interview
      
      Posté par patrick_g (site web personnel) le 04 mai 2011 à 15:06. Évalué à 7.
      
      Ben y'a seccomp quand même non ? D'ailleurs les mecs de Google disent l'utiliser dans Chrome : http://article.gmane.org/gmane.linux.ports.sparc/11622
      - [^] # Re: Bonne interview
        
        Posté par reno le 04 mai 2011 à 20:49. Évalué à 3.
        
        Merci pour le rappel de seccomp.
        
        Cependant d'après http://code.google.com/p/chromium/wiki/LinuxSandboxing ce n'est pas l'option choisie par défaut, j'ignore pourquoi..
        
        Et si tu regardes ici: http://lwn.net/Articles/347547/ l'implémentation de la sandbox a l'air très complexe même avec seccomp: leur méthode actuelle désassemble le code 'untrusted' quand même!
        Je crois qu'il y avait des patch pour seccomp pour le rendre plus simple à utiliser mais ils ont été rejeté.
        
        Hors quasiment tout ce qui est complexe est buggé, donc la situation actuelle ne me parait pas idéale..
        
        [^] # Re: Bonne interview
        
        Posté par patrick_g (site web personnel) le 05 mai 2011 à 07:23. Évalué à 5.
        
        Tiens, coïncidence, il y a justement un article LWN qui vient de sortir sur les améliorations potentielles de seccomp : https://lwn.net/Articles/441232/
        
        [^] # Re: Bonne interview
        
        Posté par bilboa le 06 mai 2011 à 00:43. Évalué à 0.
        
        ca reste du patchwork, le design de seccomp étant de stopper la possibilitée de faire des appels système
        donc ca "jail" le programme. Super mais il peut plus rien faire le programme. Bref, c'est compliqué, c'est pas clean, c'est pour palier à un système mal conçu à la base: patchwork.
        
        [^] # Re: Bonne interview
        
        Posté par djano le 06 mai 2011 à 14:40. Évalué à 4.
        
        Capsicum avait l'air très bien foutu lui.
        
        Vivement que le port sur Linux se concrétise et que ça intègre le noyau!
      - [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 06 mai 2011 à 03:29. Évalué à 1.
        
        Singularity (et ce qui le suit) n'ont rien a voir avec seccomp au niveau architectural.
        
        Un (seccomp et sandboxes similaires, y compris sous Windows) sont des approches tres brut qui essaient de mettre des limites a un systeme qui n'a jamais ete prevu pour. Cela implique des trucs bien lourd comme des proxys pour permettre certains appels qu'il faudrait permettre mais uniquement de certaines manieres, etc... et contiennent souvent des manieres de sortir de la sandbox car le systeme n'a jamais ete prevu pour avoir une sandbox complete ET utilisable, et resultat il faut faire des trucs abracadabrants et des concessions.
        
        L'autre a une architecture pensee a la base pour empecher l'enorme majorite de ces problemes par construction. C'est propre, simple et complet car inclut dans le design de base.
        
        [^] # Re: Bonne interview
        
        Posté par Nicolas Boulay (site web personnel) le 10 mai 2011 à 11:57. Évalué à 1.
        
        L'autre a une architecture pensee a la base pour empecher l'enorme majorite de ces problemes par construction. C'est propre, simple et complet car inclut dans le design de base.
        
        En gros, il enlève le V de VM ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 10 mai 2011 à 12:03. Évalué à -1.
        
        Pas compris
        
        [^] # Re: Bonne interview
        
        Posté par Nicolas Boulay (site web personnel) le 10 mai 2011 à 15:09. Évalué à 2.
        
        Les machines virtuelles de java, C# ou javascript embarquent un modèle de protection assez étanche de base. La téchnique que tu décris y ressemble beaucoup.
        
        "La première sécurité est la liberté"
        
        [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 10 mai 2011 à 20:01. Évalué à 0.
        
        C'est lie oui, cf. http://research.microsoft.com/en-us/news/features/singularity.aspx pour plus de details, ou tu peux meme aller lire le code de l'OS sur codeplex si tu veux...
        
        [^] # Re: Bonne interview
        
        Posté par Nicolas Boulay (site web personnel) le 11 mai 2011 à 09:27. Évalué à 5.
        
        Cela ressemble beaucoup aux principes des "capabilities" (capacité). Mais le problème est toujours le même : les programmeurs sont faignant et demandent souvent bien trop de droits. On peut toujours refuser ces droits mais le programme ne tournera plus.
        
        "La première sécurité est la liberté"
    - [^] # Re: Bonne interview
      
      Posté par pasBill pasGates le 06 mai 2011 à 03:38. Évalué à 0.
      
      D'où tu sors les 35 devs? Je pensais que Singularity était juste un projet de recherche des laboratoires Microsoft?
      Pour autant que je sache il n'est pas développé du tout: as-tu plus d'infos ou confonds-tu avec autre chose?
      
      35 ? :+)
    - [^] # Re: Bonne interview
      
      Posté par Martin Peres (site web personnel) le 06 mai 2011 à 15:33. Évalué à 1.
      
      D'où tu sors les 35 devs? Je pensais que Singularity était juste un projet de recherche des laboratoires Microsoft?
      Pour autant que je sache il n'est pas développé du tout: as-tu plus d'infos ou confonds-tu avec autre chose?
      
      Désolé, de ne pas avoir mis de référence, c'est que l'article de wikipedia(http://fr.wikipedia.org/wiki/Singularity) en manquait aussi. Au final, que ce soit 5, 10, 50 ou 100 développeurs, ce que je voulais dire tiens toujours.
      
      Non, je n'ai pas d'infos sur Singularity, mais le problème de créer un nouvel OS actuellement est l'implémentation des drivers. De plus, dans le cas de Singularity, masquer la gestion de la mémoire (le managé) dans le kernel, ça revient pas à faire une approche hybride entre les micro-noyaux et les noyaux monolithiques? Je suis pas convaincu de la pertinence.
      
      Sauf que Linux n'est pas non plus bien situer de ce coté: les développeurs de Chrome, une des rare application a faire justement ce contrôle des appels systèmes, se plaignaient que Linux n'offraient pas de moyen "standard" d'implémenter leur 'bac à sable'..
      
      Je pense que ça a déjà été répondu :)
      - [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 11 mai 2011 à 00:37. Évalué à 2.
        
        De plus, dans le cas de Singularity, masquer la gestion de la mémoire (le managé) dans le kernel, ça revient pas à faire une approche hybride entre les micro-noyaux et les noyaux monolithiques? Je suis pas convaincu de la pertinence.
        
        Singularity a une architecture tres speciale, il n'y a pas de separation logique (au sens des rings sur x86 par exemple) entre le kernel et le user-mode, tout tourne en ring-0, les controles d'acces se font d'autres manieres.
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 12 mai 2011 à 11:43. Évalué à -6.
        
        Singularity a une architecture tres speciale, il n'y a pas de separation logique (au sens des rings sur x86 par exemple) entre le kernel et le user-mode, tout tourne en ring-0, les controles d'acces se font d'autres manieres.
        
        Epic Fail... Pourquoi se passer de la sécurité presque gratuite apportée par la mmu? Éviter le coût du context switch userspace/kernelspace? C'est vraiment n'importe quoi! Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?
        
        [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 12 mai 2011 à 12:29. Évalué à 6.
        
        Epic Fail... Pourquoi se passer de la sécurité presque gratuite apportée par la mmu? Éviter le coût du context switch userspace/kernelspace? C'est vraiment n'importe quoi! Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?
        
        Epic fail ? Non l'epic fail c'est toi qui ne comprend pas Singularity et qui n'a pas compris les avantages d'enlever cette barriere ainsi que les barrieres entre processus (message passing sans copie necessaire)
        
        Et il se passe quoi si j'écris un programme non managé sur cet "OS"? J'ai accès à toute la ram, aux périphériques, etc...?
        
        Tu vas le faire tourner comment ton programme non manage exactement ? T'as un API miracle pour le lancer ?
        
        Serieusement, ranges ton arrogance dans l'armoire, et ait un minimum d'humilite. Tu ne comprends visiblement pas grand-chose a l'architecture de Singularity et ses avantages / desavantages , plutot qu'emettre des affirmations farfelues je te suggeres d'y mettre bcp plus de conditionel.
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 12 mai 2011 à 12:58. Évalué à -6.
        
        Epic fail ? Non l'epic fail c'est toi qui ne comprend pas Singularity et qui n'a pas compris les avantages d'enlever cette barriere ainsi que les barrieres entre processus (message passing sans copie necessaire)
        
        Bla, c'est du vent tout ça. Un processus qui tourne en ring0 reste un processus en ring0 même si y'a le miracle .net et de la vérification statique avant. Un processus en ring0 accède à ce qu'il veut, fait ce qu'il veut et court-circuite le kernel si il veut. C'est irresponsable comme concept.
        
        Le coup du message passing (sans copies? et alors?) n'enlève rien à ce problème.
        
        Tu vas le faire tourner comment ton programme non manage exactement ? T'as un API miracle pour le lancer ?
        
        Un processeur exécute du x86 et pas du C#, y'a pas besoin d'API pour exécuter du code, simplement une zone mémoire où s'écrire et $ip placé au bon endroit.
        
        Comment tu peux oser dire que .net empêche $ip d'aller dans cette zone? Alors oui tu peux marquer les pages mémoires avec les bons droits et utiliser le bit NX pour grandement empêcher ça mais un processus en ring0 a la possibilité d'enlever ce bit. Faire confiance à l'analyse statique pour vérifier ça, c'est vraiment chercher la merde.
        
        [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 12 mai 2011 à 18:39. Évalué à 4.
        
        Bla, c'est du vent tout ça. Un processus qui tourne en ring0 reste un processus en ring0 même si y'a le miracle .net et de la vérification statique avant. Un processus en ring0 accède à ce qu'il veut, fait ce qu'il veut et court-circuite le kernel si il veut. C'est irresponsable comme concept.
        
        N'importe quoi. Tu m'expliques comment ce processus passera la verification ?
        
        Un processeur exécute du x86 et pas du C#, y'a pas besoin d'API pour exécuter du code, simplement une zone mémoire où s'écrire et $ip placé au bon endroit.
        
        Tu n'as clairement rien compris, ton code ne s'executera pas si il ne peut pas etre lance car il n'a pas passe la verification.
        
        Comment tu peux oser dire que .net empêche $ip d'aller dans cette zone? Alors oui tu peux marquer les pages mémoires avec les bons droits et utiliser le bit NX pour grandement empêcher ça mais un processus en ring0 a la possibilité d'enlever ce bit. Faire confiance à l'analyse statique pour vérifier ça, c'est vraiment chercher la merde.
        
        Et comment tu mets l'addresse de $ip a ce que tu veux dans Singularity ? Tu ne peux pas, tout comme tu ne peux pas ecrire d'assembleur ou autre code binaire qui s'executera directement sous Singularity.
  - [^] # Re: Bonne interview
    
    Posté par bilboa le 06 mai 2011 à 00:41. Évalué à 2.
    
    Ben avant de dire n'importe quoi.. :)
    
    1/ 80% des exploits proviennent de failles bidons (genre "jai laissé ma clée ssh trainer avec un pass bidon")
    2/ qui sont transformé en "full exploit" via une faille kernel (100% des kernels ont des failes "instant root")
    
    Singularity palie à ca et au manque de rigueur du code (qui est impossible en C).
    Si ca parce que c'est Microsoft, il y a d'autre OS du même type, simplement moins connus.
    Singularity contrôle aussi les accès mémoire des applis et appels système.
    
    Pour le contrôle des appels les appels système sous Linux il y a RSBAC/SeLinux/...
    - [^] # Re: Bonne interview
      
      Posté par Martin Peres (site web personnel) le 06 mai 2011 à 15:24. Évalué à 1.
      
      Pour le contrôle des appels les appels système sous Linux il y a RSBAC/SeLinux/...
      
      Yap, je sais, mais ça suffit pas et c'est super lourd à mettre en place. C'est sur ce sujet de recherche que j'ai travaillé en tant qu'étudiant de master à l'ENSI de Bourges.
      
      Y'a quelques papiers de recherche sur le sujet. Il y a notamment la thèse de Jonathan Rouzaud-Cornabas (http://www.arrouan.be/perso/?page_id=42) qui traite du problème d'empêcher les flux d'informations.
      
      Avec le système décrit dans la thèse, il devient possible d'écrire en moins de 5 lignes une règle qui empêche qu'un utilisateur exécute un binaire qu'il aurait lui même téléchargé. Il est aussi possible d'empêcher des flux indirect de transfert d'information quand le flux direct n'est pas lui même possible. Cela permet d'éviter que le fichier des mots de passes de firefox soit accessible par le client mail même si firefox ouvre le fichier et le ré-enregistre dans /tmp (endroit où le client mail a normalement le droit de lire).
    - [^] # Re: Bonne interview
      
      Posté par Martin Peres (site web personnel) le 06 mai 2011 à 15:51. Évalué à 5.
      
      1/ 80% des exploits proviennent de failles bidons (genre "jai laissé ma clée ssh trainer avec un pass bidon")
      
      Mouais, pas convaincu mais je vois très bien d'où tu veux en venir et on y peut rien :s. Cela dit, le premier vecteur d'attaque dépend de la cible. Les attaques sur les serveurs, c'est plus des failles dans les services que les clés ssh qui trainent :)
      
      2/ qui sont transformé en "full exploit" via une faille kernel (100% des kernels ont des failes "instant root")
      
      Escalade des privilèges, en effet. Les failles à ce niveau là ne viennent pas forcement que des modules, elles peuvent venir du matériel aussi (DMA). Il n'y a pas que les NULL pointer dereference comme failles dans le kernel. Singularity ne peut rien faire contre les exploitations abusives du matériel.
      
      Singularity palie à ca et au manque de rigueur du code (qui est impossible en C).
      
      Je dirai qu'ils prétendent y palier, on a pas de code à tester que je sache, si?
      
      Si ca parce que c'est Microsoft, il y a d'autre OS du même type, simplement moins connus.
      
      Ça serait le kernel Linux qui voudrait faire ça, j'aurai la même réaction en plus violente :D Je suis au contraire bien content que Microsoft dépense un peu de son argent dans la recherche plutôt que la pub ou autre.
      
      Singularity contrôle aussi les accès mémoire des applis et appels système.
      
      Pour les appels systèmes, ok.
      Pour les accès mémoire des processus, Singularity base sa décision d'accepter ou non l'accès sur quoi?
      
      C'est exactement mon sujet de mémoire de master, abuser la MMU pour récupérer des page_fault sur les pages mémoires "protégées" et vérifier ou non que l'accès soit valide ou non. Le moteur de décision de l'autorisation ou non venait du moteur du moteur d'SELinux (AVC).
      
      Perso, je pense pas de bien de Singularity car le managé donne un faux sentiment de sécurité et demande la ré-écriture d'un OS pour empêcher quoi? Une ou deux types de failles en laissant les autres totalement ouvertes...
      - [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 11 mai 2011 à 00:33. Évalué à 3.
        
        Je dirai qu'ils prétendent y palier, on a pas de code à tester que je sache, si?
        
        http://singularity.codeplex.com/
        
        Tu peux meme lire le code source si ca te chante...
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 12 mai 2011 à 12:02. Évalué à -3.
        
        Merci, ça m'a permis de lire des âneries derrière cette idée de Singularity:
        
        1) Cool, vérifions statiquement qu'un programme se comporte comme on veut et faisons encore une fois abstraction du hardware.
        
        2) Et puis le choix du C# pour éviter les débordements de tampon, trop bien! C'était pas possible de faire une API pour la gestion des 3/4 pauvres chaines de caractère qui traînent dans le noyau? Ah ben non, c'est vrai, on est dans un modèle de kernel propriétaire et on peut pas faire confiance aux devs de drivers. C'est ça leur problème! Un kernel DOIT être ouvert et développé par tous les créateurs de drivers.
        
        3) Cool, on va faire un OS qui réagit différemment suivant le type de programme, juste pour rigoler. Parce que c'est vrai, le kernel est mieux placé pour juger des besoins d'un programme plutôt que le programme lui même. C'est ça le principe des manifests (outre l'analyse statique pour vérifier que le comportement est bon avant de l'installer). Sérieux, ils pourraient pas faire comme tout le monde et proposer un gestionnaire de paquet et des dépôts/app store? Eux peuvent être vérifiés statiquement.
        
        Au final, je trouve qu'il ont bien choisi le nom. Avec ce kernel, ils approchent de la Singularity et du trou noir que pourrait être l'informatique, gigantesque (dépend d'un analyseur statique!), invérifiable, instable et affreusement complexe.
        
        [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 12 mai 2011 à 12:23. Évalué à 4.
        
        1) Et ? Tu m'expliques le probleme ?
        2) Si tu crois que C# se limite a debordements de tampons c'est que tu n'as rien compris a C# et encore moins a Singularity. Ensuite si tu es assez naif pour croire que les problemes de gestion de tampon se reglent avec une API quelconque c'est que tu n'as rien compris a la programmation...
        3) De nouveau, tu n'as rien compris, un gestionnaire de paquets depot/app store n'a rien a voir avec la problematique en jeu, ces manifestes c'est pas une histoire de dependance ou securite sur le paquet lui-meme
        
        Pour te donner un bon exemple, tu n'as visiblement rien compris a l'utilite de C# en relation au fait qu'il n'y a pas besoin de barriere kernel/user par exemple.
        
        Pour le reste, tu m'excuseras de bien rigoler sur ton arrogance et la facilite avec laquelle tu rejettes un truc sur lequel plus d'une dizaine de chercheurs experiementes bossent, car visiblement tu ne comprends meme pas le sujet.
        
        Perso je te suggeres de bien reflechir a 2 fois avant de parler de sujets que tu ne comprends pas, et surtout de bien te poser la question suivante : un tas de gars plutot bons et avec plus d'experience que moi bossent dessus, sont-ils vraiment si idiots que ca ou ai-je rate un truc ?
        
        Ca t'aidera bcp dans ta carriere.
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 12 mai 2011 à 13:49. Évalué à 1.
        
        1) Et ? Tu m'expliques le probleme ?
        
        Il est impossible de prouver une propriété en faisant de l'analyse statique pour la bonne et simple raison qu'il est impossible pour un programme de vérifier tous les cas. C'est un truc que tu vois dans les 20 premières minutes d'un cours sur l'analyse statique. La seule solution pour prouver le bon fonctionnement d'un programme en un temps raisonnable, c'est de générer des tonnes de faux négatifs. Ça revient à demander à un compilateur de générer des patterns de code. Pourquoi pas, mais c'est documenté? Quid de la vitesse d'exécution?
        
        Un exemple, tu peux vérifier que les appels systèmes sont bien les bons et appelés seulement avec une adresse immédiate (miam le cassage de programmes existants).
        
        Mais au final, c'est quoi un appel système dans un OS comme ça? Ça existe pas, c'est plus un espèce de gros tas qui prétend être tenu en place par de l'analyse statique de tous les cotés.
        
        2) Si tu crois que C# se limite a débordements de tampons c'est que tu n'as rien compris a C# et encore moins a Singularity.
        
        Tu lis vraiment ce que tu veux lire. C'est le seul intérêt de C# citée dans http://research.microsoft.com/en-us/news/features/singularity.aspx . Je m'arrête donc là.
        
        Ensuite si tu es assez naif pour croire que les problemes de gestion de tampon se reglent avec une API quelconque c'est que tu n'as rien compris a la programmation...
        
        Si tu veux vraiment éviter les buffers overflows, il faut contrôler la création de buffers puis tous les accès subséquents. La seule façon crédible de faire ça et vérifier à l'exécution et la seule façon de vérifier et de faire des processeurs qui soient au courant de la taille de ton "buffer".
        Ça a déjà été "fait": http://www.cc.gatech.edu/~idoud/documents/TAINTTC.pdf
        
        Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
        
        Et je me répète, mais y'a pas que les processus qui font des accès mémoire, le matériel aussi. Et le matériel peut être programmé pour faire un accès mémoire qui va modifier les bits que tu veux au bon endroit même si la page mémoire est marquée comme ro (et oui).
        
        3) De nouveau, tu n'as rien compris, un gestionnaire de paquets depot/app store n'a rien a voir avec la problematique en jeu, ces manifestes c'est pas une histoire de dependance ou securite sur le paquet lui-meme
        
        Mais oui, je comprend rien, regarde plutôt ça:
        
        Singularity’s third unique architectural feature, called “manifest-based programs,” represents another shift in orientation. Traditionally, operating systems have had no “knowledge” of a program’s composition, its purpose, or the resources it uses. Presented with a set of bits, the operating system would simply run them. Singularity, with its emphasis on overall system dependability, takes a different approach to ensure that a new program won’t “break” the programs already on board.
        
        Comment ils font? 2 choix, soit le manifest décrit le fonctionnement du programme de façon formelle de façon à ce que le kernel puisse voir si c'est normal ou pas.
        Soit le manifest ne contient que des informations de plus haut niveau qui permettent à l'OS de choisir de l'exécuter ou pas.
        
        Dans le 2ème cas, le kernel devrait vérifier que le manifest soit pas bidonné, donc, il faut utiliser l'analyseur statique pour vérifier le code.
        
        J'aime l'idée du manifest qui indique les besoins d'un programme, c'est une très bonne chose. Mais c'est pas au kernel de vérifier ça! C'est à un dépôt de vérifier ça puis de livrer les applications à l'utilisateur signées par le dépôt.
        
        Alors, c'est qui qui a rien compris?
        
        Quand à l'arrogance, je te retourne le compliment. Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
        
        De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
        
        Je le répète, je suis à l'aise avec ce sujet car j'ai fais mon mémoire de master sur la gestion d'accès aux pages mémoires, j'ai étudié la sécurité durant 3 ans (spécialité mobilité et virtualisation) et je débute dans l'écriture de driver (je bosse sur Nouveau, le driver libre nvidia). Tu fais quoi toi pour me traiter d'incapable?
        Et puis si encore j'étais le seul: http://www.ok-labs.com/blog/entry/about-security-singularity-vs-l4-part-2/ Et j'ai passé 10s sur google pour le trouver.
        
        Je ne traite pas Microsoft d'idiots, juste de personnes qui pensent avec le porte monnaie. Dire qu'ils travaillent sur un OS sécurisé, c'est dire on essaye de faire mieux, ça rassure et donc, ça rapporte à plus ou moins long terme.
        
        [^] # Re: Bonne interview
        
        Posté par Antoine le 12 mai 2011 à 16:03. Évalué à 2.
        
        Si tu veux vraiment éviter les buffers overflows, il faut contrôler la création de buffers puis tous les accès subséquents. La seule façon crédible de faire ça et vérifier à l'exécution et la seule façon de vérifier et de faire des processeurs qui soient au courant de la taille de ton "buffer".
        
        Donc tu penses qu'en Java, Python, Ruby... tu peux crasher un processus en faisant un accès hors limites de tableau, sous prétexte qu'il n'y a pas de CPU idoine ?
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 12 mai 2011 à 18:36. Évalué à 1.
        
        Donc tu penses qu'en Java, Python, Ruby... tu peux crasher un processus en faisant un accès hors limites de tableau, sous prétexte qu'il n'y a pas de CPU idoine ?
        
        C'est simple, si ça plante pas, c'est que les accès aux éléments d'un tableau sont vérifiés à l’exécution. Bonjour les perfs quand tu fais que manipuler des structures de données comme dans ... un kernel?
        
        Si ça te laisse faire (depuis quand ça devrait crasher le processus? C'est juste quand tu sors des pages mémoires qui t'ont été mappées par le kernel dans ta mémoire virtuelle que tu te récupères un segfault), alors c'est que c'est pas vérifié. C'est ce que fais C/C++.
        
        On peut avoir le meilleur des 2 mondes (le débug facile de Python/Ruby/Java) et les perfs de C grâce à valgrind (userland uniquement) qui te vérifiera tous tes accès mémoires. Mais faudra coder en C pour avoir les perfs de C.
        
        [^] # Re: Bonne interview
        
        Posté par Antoine le 13 mai 2011 à 14:14. Évalué à 2.
        
        C'est simple, si ça plante pas, c'est que les accès aux éléments d'un tableau sont vérifiés à l’exécution.
        
        Si tu as du code du genre :
        
        int foo[6]; int i; for (i=0; i<6; i++) foo[i] = i;
        
        J'espère que tu conviendras qu'il n'y a pas besoin de vérification à l'exécution pour être sûr que la boucle n'accède pas en-dehors du tableau ?
        
        Il y a aussi la notion de compilation juste à temps que tu sembles ignorer : un certain nombre de vérifications peuvent être faites à ce moment, lorsqu'on a des infos plus fines sur le contexte d'exécution.
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 15 mai 2011 à 11:50. Évalué à -2.
        
        J'espère que tu conviendras qu'il n'y a pas besoin de vérification à l'exécution pour être sûr que la boucle n'accède pas en-dehors du tableau ?
        
        Il y a aussi la notion de compilation juste à temps que tu sembles ignorer : un certain nombre de vérifications peuvent être faites à ce moment, lorsqu'on a des infos plus fines sur le contexte d'exécution.
        
        Oui, je suis 100% d'accord, mais dans l'absolu, un compilateur (JIT ou pas) ne peut pas toujours prouver que l'on ne sortira pas du tableau. C'est plus le rôle d'un analyseur statique de faire ça, et même là, c'est pas toujours la joie.
        
        [^] # Re: Bonne interview
        
        Posté par lasher le 15 mai 2011 à 20:47. Évalué à 4.
        
        [...] un compilateur (JIT ou pas) ne peut pas toujours prouver que l'on ne sortira pas du tableau. C'est plus le rôle d'un analyseur statique de faire ça [...]
        
        Mhh. Si on parle d'analyse statique, par définition c'est le rôle du compilo. Ça fait un bail que les compilateurs font plus que de la simple traduction de code source vers assembleur...
        
        [^] # Re: Bonne interview
        
        Posté par pasBill pasGates le 12 mai 2011 à 18:58. Évalué à -1.
        
        Il est impossible de prouver une propriété en faisant de l'analyse statique pour la bonne et simple raison qu'il est impossible pour un programme de vérifier tous les cas. C'est un truc que tu vois dans les 20 premières minutes d'un cours sur l'analyse statique. La seule solution pour prouver le bon fonctionnement d'un programme en un temps raisonnable, c'est de générer des tonnes de faux négatifs. Ça revient à demander à un compilateur de générer des patterns de code. Pourquoi pas, mais c'est documenté? Quid de la vitesse d'exécution?
        
        Qui t'a dit que ca s'arrete a l'analyse statique ?
        
        Tu lis vraiment ce que tu veux lire. C'est le seul intérêt de C# citée dans http://research.microsoft.com/en-us/news/features/singularity.aspx . Je m'arrête donc là.
        
        Et tu rates la moitie du truc quand tu t'arretes a une page d'introduction
        
        Si tu veux vraiment éviter les buffers overflows, il faut contrôler la création de buffers puis tous les accès subséquents. La seule façon crédible de faire ça et vérifier à l'exécution et la seule façon de vérifier et de faire des processeurs qui soient au courant de la taille de ton "buffer".
        Ça a déjà été "fait": http://www.cc.gatech.edu/~idoud/documents/TAINTTC.pdf
        
        Et tu crois que qqe APIs suffisent pour un kernel ? Tu n'as visiblement aucune idee de ce qu'un kernel contient.
        
        Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
        
        Si tu crois que .net fait de la verif a la compilation, tu n'as rien ocmpris a .NEt, c'est a l'execution que c'est verifie, et c'est pas interprete (tout comme Java).
        
        Et je me répète, mais y'a pas que les processus qui font des accès mémoire, le matériel aussi. Et le matériel peut être programmé pour faire un accès mémoire qui va modifier les bits que tu veux au bon endroit même si la page mémoire est marquée comme ro (et oui).
        
        Et comment tu lancera un soft qui programmera ton materiel sous Singularity ? Tu ne peux pas.
        Tu crois pour je ne sais quelle raison que tu peux faire tourner le code que tu veux sous Singularity, c'est pas le cas.
        
        Comment ils font? 2 choix, soit le manifest décrit le fonctionnement du programme de façon formelle de façon à ce que le kernel puisse voir si c'est normal ou pas.
        Soit le manifest ne contient que des informations de plus haut niveau qui permettent à l'OS de choisir de l'exécuter ou pas.
        
        Dans le 2ème cas, le kernel devrait vérifier que le manifest soit pas bidonné, donc, il faut utiliser l'analyseur statique pour vérifier le code.
        
        J'aime l'idée du manifest qui indique les besoins d'un programme, c'est une très bonne chose. Mais c'est pas au kernel de vérifier ça! C'est à un dépôt de vérifier ça puis de livrer les applications à l'utilisateur signées par le dépôt.
        
        Pourquoi centraliser qqe chose qui n'a pas besoin d'etre centralise ? Si un depot ne contient pas le soft que tu veux alors tu peux pas le lancer ? Super
        
        à l'arrogance, je te retourne le compliment. Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
        
        Parce que tout le monde ne veut pas ecrire un OS avec les attributs de Singularity, tout comme tout le monde ne mange pas que des fettuccine comme pates.
        
        De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
        
        Il y a toute la partie controle d'acces que visiblement tu as rate.
        
        Je le répète, je suis à l'aise avec ce sujet car j'ai fais mon mémoire de master sur la gestion d'accès aux pages mémoires, j'ai étudié la sécurité durant 3 ans (spécialité mobilité et virtualisation) et je débute dans l'écriture de driver (je bosse sur Nouveau, le driver libre nvidia). Tu fais quoi toi pour me traiter d'incapable?
        
        Je ne te traite pas d'incapable mais d'arrogant. Quand a moi, ca fait plus de 10 ans que je bosses chez MS, dont plus de 6 sur la securite de l'OS et 4 sur la stack reseau, dans le kernel. On va dire que la securite d'un OS je connais.
        
        Et puis si encore j'étais le seul: http://www.ok-labs.com/blog/entry/about-security-singularity-vs-l4-part-2/ Et j'ai passé 10s sur google pour le trouver.
        
        Super, quel rapport ? Il parle du fait qu'il existe des bouts de code non-manage, ca ne dit rien sur l'architecture de Singularity a part que L4 est plus petit et plus facilement verifiable..
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 12 mai 2011 à 19:56. Évalué à -2.
        
        Et tu rates la moitie du truc quand tu t'arretes a une page d'introduction
        
        Ok, si les concepts généraux ne sont pas dans la page d'intro, dans ce cas là la page est mal faite. Je lirai peut être un jour les articles, en attendant, je crois pas au futur du truc.
        
        Et tu crois que qqe APIs suffisent pour un kernel ? Tu n'as visiblement aucune idee de ce qu'un kernel contient.
        
        Roo, calme toi. Je te parle d'une interface de manipulation de tableau avec vérification des accès à l'exécution, et toi tu pars direct sur; ça suffit pas pour faire un kernel. Tu dérailles là, bien sûr que ça suffit pas.
        
        Maintenant explique moi comment fait .net pour empêcher les buffers overflow alors? C'est de la programmation orientée objet, et une vérification à la compilation à moins que .net interprète ton code.
        
        Si tu crois que .net fait de la verif a la compilation, tu n'as rien ocmpris a .NEt, c'est a l'execution que c'est verifie, et c'est pas interprete (tout comme Java).
        
        En effet, j'ai dis de la grosse merde là. J'ai très très mal formulé ce que je voulais dire. Tu as 100% raison là dessus.
        
        Et comment tu lancera un soft qui programmera ton materiel sous Singularity ? Tu ne peux pas.
        Tu crois pour je ne sais quelle raison que tu peux faire tourner le code que tu veux sous Singularity, c'est pas le cas.
        
        Et tu crois pour je ne sais quelle raison qu'on arrivera jamais à trouver une faille qui va faire qu'on va pouvoir exécuter du code. C'est ça que je trouve scandaleux de la part d'une équipe de sécurité, avoir une confiance aveugle en son système au point de faire tourner tout programme en ring0.
        
        Pourquoi la recherche sur la sécurité mémoire ne s'est pas arrêtée lors de l'arrivée de .net et C#? Oh, mais que je suis bête, c'est simplement parce que C# ne résout rien...
        
        Parce que tout le monde ne veut pas ecrire un OS avec les attributs de Singularity, tout comme tout le monde ne mange pas que des fettuccine comme pates.
        
        Ou simplement aussi que ça ralentit énormément les accès mémoires. Je pense que là dessus, on a plus rien à dire.
        
        De toute façon, C# ne peut être meilleur que la virtualisation ... qui n'est pas de la sécurité.
        Il y a toute la partie controle d'acces que visiblement tu as rate.
        
        Ou simplement tu oublies encore les failles dans les drivers. La virtualisation ne fait qu'augmenter la surface d'attaque. Actuellement, root sur une VM rime avec root sur l'host tellement il y a de failles.
        
        Je ne te traite pas d'incapable mais d'arrogant. Quand a moi, ca fait plus de 10 ans que je bosses chez MS, dont plus de 6 sur la securite de l'OS et 4 sur la stack reseau, dans le kernel. On va dire que la securite d'un OS je connais.
        
        Moi je trouve arrogant de la part de l'équipe de Singularity d'enlever l'interface userland/kernel.
        
        Sinon, ça veut dire que tu as participé à la création de MIC? J'ai bien aimé l'idée de forcer les gens à utiliser un système de contrôle d'accès mandataire, mais le faire se baser sur des niveaux d'intégrité, c'est vraiment pas géant à mon goût. Je suis plus fan des labels et de la création de domaines car ça permet de segmenter les tâches en activités.
        
        Et puis si encore j'étais le seul: http://www.ok-labs.com/blog/entry/about-security-singularity-vs-l4-part-2/ Et j'ai passé 10s sur google pour le trouver.
        
        Super, quel rapport ? Il parle du fait qu'il existe des bouts de code non-manage, ca ne dit rien sur l'architecture de Singularity a part que L4 est plus petit et plus facilement verifiable..
        
        C'est vrai que vérifiable et sécurité, c'est pas associé du tout. M'enfin, c'était pas le truc que je voulais montrer. Tu me demandes comment le code malicieux pour arriver comme ça et être exécuté. Moi je dis, prouve moi que c'est impossible. Jusqu'à preuve du contraire, je continuerai à penser que c'est possible, donc ça va arriver.
        
        En fait, je trouve nos approche vraiment opposées. Pour moi, un pourrait potentiellement arriver si les étoiles sont alignées etc... = arrive. Pour toi, c'est un pourrait arriver = peu probable.
        
        [^] # Re: Bonne interview
        
        Posté par TImaniac (site web personnel) le 14 mai 2011 à 16:44. Évalué à 6.
        
        C'est ça que je trouve scandaleux de la part d'une équipe de sécurité, avoir une confiance aveugle en son système au point de faire tourner tout programme en ring0.
        
        En même temps c'est tout aussi scandaleux de faire confiance aux ring qui s'appuie sur du matos tout aussi potentiellement buggé... sans être patchable. Tu fais quoi demain si tu te retrouves avec une faille de sécu énorme dans une génération de proc grand public ? Le rôle de base d'un OS c'est de faire abstraction du matos, l'idée d'une sécurité qui fait abstraction de mécanisme hardware est donc tout à fait pertinente.
        
        Pour moi, un pourrait potentiellement arriver si les étoiles sont alignées etc... = arrive. Pour toi, c'est un pourrait arriver = peu probable.
        
        Et vu qu'il est impossible de prouver que les étoiles ne seront jamais alignées, il est évident que la meilleur approche consiste uniquement à en diminuer la probabilité.
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 15 mai 2011 à 11:59. Évalué à 4.
        
        En même temps c'est tout aussi scandaleux de faire confiance aux ring qui s'appuie sur du matos tout aussi potentiellement buggé... sans être patchable. Tu fais quoi demain si tu te retrouves avec une faille de sécu énorme dans une génération de proc grand public ? Le rôle de base d'un OS c'est de faire abstraction du matos, l'idée d'une sécurité qui fait abstraction de mécanisme hardware est donc tout à fait pertinente.
        
        Sur le fond tu as pas tord, mais faut pas exagérer non plus. Le concept de ring est assez simple à implémenter et puis, c'est pas dur pour la MMU de regarder le ring actuel et regarder les flags de la page mémoire pour comparer et générer ou non un page_fault.
        
        Comparer ça aux milliers de lignes nécessaires dans l'OS pour arriver à se passer du concept de ring, c'est osé ;)
        
        Pour le coup de l'OS qui doit faire abstraction du matos, c'est vrai d'un point de vue userspace, mais pas d'un point de vue kernel space. Le kernel doit utiliser autant que possible le matériel car il est plus rapide et consomme moins d'énergie que le software.
        
        [^] # Re: Bonne interview
        
        Posté par TImaniac (site web personnel) le 15 mai 2011 à 12:44. Évalué à 5.
        
        Comparer ça aux milliers de lignes nécessaires dans l'OS pour arriver à se passer du concept de ring, c'est osé ;)
        
        Pas tant que ça :
        * même simple, le concept de ring reste "hardware" : en cas de faille, t'es pas dans la merde. La simplicité ayant pour seul avantage de diminuer la probabilité, son apparition est critique puisque non corrigeable.
        * même simple et non buggé, le concept de ring ne résoud rien s'il y a un bug dans le kernel à travers un appel système : celui-ci peut être exploité et obtient un accès root, ce qui supprime tout le gain de fiabilité offert par la simplicité du ring.
        * la "simplicité" a un coup non négligeable (task-switching), qui devient de plus en plus problématique dans un contexte d'architectures et de softs multi-threadés.
        
        Singularity tente une approche différente, l'avenir nous dira si c'était la bonne solution, mais sur le papier c'est pas plus abhérent que le ring, et comparable sur le plan de la sécurité :
        * pas d'utilisation des ring hardware : en cas de bug, ca reste patchable. Et puis portable, on le voit aujourd'hui, les architectures CPU bougent.
        * pour limiter les bugs dans le kernel, utilisation d'un langage beaucoup plus sûr (Sing# : environnement managé, type-safe, programmation par contrat).
        * pour limiter les programmes "dangereux", aucun code natif autorisé, que du code vérifiable ET vérifié avant toute exécution (à l'installation).
        * Effet de bord : pas d'utilisation des rings, donc coût de task-switching limité.
        
        Les OS actuels sont "by-design" très mal conçu au niveau sécurité : on fait tourner le code et on prie pour n'avoir laissé aucune faille de sécurité dans les nombreux appels systèmes, qui sont eux-même écrits dans un langage "by-design" nul au niveau sécurité (le langage C). Sans parler des impacts en userland sur les données utilisateurs qui sont difficilement maîtrisables.
        
        Singularity a une approche totalement différente :
        * on vérifie en amont que le soft n'est pas dangereux
        * on l'exécute dans le contexte d'une machine virtuelle en cas de bug dans l'étape précédente
        * on impose un modèle de machine virtuelle qui limite grandement les bugs involontaires des programmeurs pouvant conduire à des failles de sécu.
        
        [^] # Re: Bonne interview
        
        Posté par Martin Peres (site web personnel) le 16 mai 2011 à 12:04. Évalué à 0.
        
        Bon, on va dire que j'ai peur de voir un modèle comme ça appliqué parce que le système de vérification de code est complexe.
        
        En tous cas, bonne explication! Cela dit, pourquoi ne pas simplement vérifier le code en userspace, pourquoi ré-écrire le code du kernel. Je trouve vraiment pas ça pertinent. Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
        
        On retombe donc sur un problème de vitesse de résolution de la faille et sur ce terrain, le libre a son intérêt. Même si le kernel n'est pas prouvé, le temps entre la découverte d'une faille et l'arrivée du patch est généralement de quelques heures. Il suffit d'appliquer le correctif sur son kernel et tout est bon. Cela dit, quid des failles pas publiques? Là, on est obligé de limiter l'exécution de code à des binaires plus ou moins prouvés par l'expérience. Sur ce point, l'aspect centralisateur des dépôts est un bon point car les vérifications de l'un participe aux autres. Et puis il est toujours possible de faire tourner tous les analyseurs statiques qu'on veut sur les sources.
        
        Au final, je dirai que l'idée a le mérite d'exister. Comme tu dis, on verra si ça marche en pratique.
        
        [^] # Re: Bonne interview
        
        Posté par TImaniac (site web personnel) le 16 mai 2011 à 14:58. Évalué à 4.
        
        pourquoi ré-écrire le code du kernel
        
        Déjà c'est une architecture micro-kernel, les drivers ne sont pas dedans : autant que le kernel soit le plus fiable possible, et donc écrit dans un langage plus "sûr". L'idée étant de limiter le C et l'assembleur au strict minimum (bootstrap, HAL). Niveau sécurité, c'est toujours ça de gagné.
        
        Ensuite l'intérêt est de faire tourner le kernel dans le même environnement que les process, pour éviter de le coût des changements de contexte : celà suppose donc d'avoir le même niveau de confiance dans les process que dans le kernel, et donc les mêmes technos (VM/C#/Sing#).
        
        . Qu'on le veuille où non, les drivers utiliseront toujours des pointeurs et c'est dans les drivers que les failles seront trouvées.
        
        Dans Singularity, les drivers sont écrits en Sing# (dérivé de C#) : c'est un langage type-safe qui t'offre un certain nombre de garanties à la compilation contre les bugs les plus classiques, et une vérification de tous les accès mémoires, même par pointeur, afin de t'assurer que la mémoire n'est jamais corrompu (les explications détaillées, notamment à partir de la section 3 dans le doc http://www.cs.kuleuven.ac.be/conference/EuroSys2006/papers/p177-fahndrich.pdf ). Un driver tournant donc dans un environnement "managé", il est isolable, il peut exploser dans son coin, il emporte pas le kernel avec lui dans sa chute.
        
        Sur ce point, l'aspect centralisateur des dépôts est un bon point car les vérifications de l'un participe aux autres. Et puis il est toujours possible de faire tourner tous les analyseurs statiques qu'on veut sur les sources.
        
        Attention, les vérificateurs statiques tournent sur le bytecode et pas sur le code source : bref, chaque "binaire" est vérifié et validé par le kernel lors de son installation. On s'en tapes donc pas mal du côté centralisateur, ce qui compte c'est d'imposer une vérification par le kernel des binaires (qui ne contiennent aucun code natif et invérifiable donc).
        
        Le seul véritable problème dans l'approche de Singularity, c'est l'absence totale de compatibilité avec les softs existants qui produisent du code non vérifable (du code natif). Celà peut paraître rédhibitoire, mais en même temps sur des plateformes "nouvelles" (exemple Windows Phone 7), ils ont franchit le pas : toute application doit être écrite dans du code vérifiable, et vérifier avant mise sur le market.
        
        D'après la doc pointée ci-dessus, ils réfléchissent à intégrer la protection "hardware" à base de ring pour sandboxer les applis natives.
# Merci

Posté par kuroineko le 04 mai 2011 à 16:10. Évalué à 5.

Intéressant d'avoir son point de vue complet, sur une multitude de sujets annexes.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.